Goffena, Robert wrote:
Hi all,
I get an assert failure when trying to execute Xalan code in debug
mode. Debug mode complains about
PlatformSupport\XalanICUMessageLoader.cpp line 145.
That line and the few above it are located in
XalanICUMessageLoader::XalanICUMEssageLoader(MemoryManager &theManager),
and look like the following:
m_localeBundle = ures_open(sPackageName, szLocal, &err);
If (!U_SUCCESS(err) || m_localeBundle ==0)
{
Assert(0);
}
This indicates the message loader could not find the resource bundle
containing the messages.
I checked out
http:/source.icu-project.org/repos/icu/icu/tags/release-3-8-1 of icu.
If you read my reply to your first email "What Version Of ICU Does Trunk
Use," on 2009-04-30, you'll see I stated that if you want to use the ICU
message loader, you need ICU 3.2.1 or earlier. This is because the ICU
changed the way they name resources, and the Xalan-C code has not been
updated to reflect the changes. Unfortunately, it's not trivial, and it
involves some tricky changes to the make system.
I checked out revision 762403 of
http://svn.apache.org/repos/asf/xalan/c/trunk.
I generated and applied the attached patches to allow building of 64 and
32 bit libraries and to allow the resulting libraries to coexist (ie:
instead of writing libraries to bin, I modified to write to
$(PlatformName)/$(ConfigurationName)).
I assume you mean you changed the ICU project files to do that. There
is no reason to change any of Xalan-C's options.
Note also that there is a new environment variable in the Xalan project
files called "ICUROOT64" which you can use instead of "ICUROOT". Note
that "ICUROOT" will still work for 64-bit builds, but the project files
will search "ICUROOT64" first. This means you can have two different
builds of the ICU, and not be forced to modify the ICU project files.
I use the XalanICU solution.
Which means you're using the ICU message loader, which is not supported
with ICU 3.8.1.
Gentest.exe from icu seems to work in release and debug builds, if I
understand what gentest.exe does.
Threadtest.exe, XPathTest.exe and TestXSLT.exe, from Xalan debug build,
cause the aforementioned assert statement to fail. Release builds of
those tests succeed.
Assertions are not enabled in release builds, so the failure is still
there, but you don't see it.
Any ideas what I have done wrong? Where I should look to fix this problem?
Fortunately, there's an easy solution: just use the Xalan solution, and
build the "with ICU" configurations for a version of Xalan-C that uses
the ICU for format-number() support and collation. There's no
compelling reason I know of to use the ICU message bundle format.
Dave
