Michael Ellery wrote:
David Bertoni wrote:
I'm not sure. Are you certain the resource DLL is being built with
ICU 3.2.1? You can verify this by looking at the build output. You
should see a line like the following:
What is the resource DLL? Is that XalanMessages_1_10.dll? (or
XalanMessages_1_10D.dll for debug).
Yes. The .dat file is produced by the build process, but is not required,
because its contents are in the resource DLL.
Check your path to make sure it's not pointing to a newer version of the
ICU. There's a glitch in the Makefiles where versions of the ICU binaries
that are in the path will be used instead of the one specified by the
ICUROOT environment variable.
If you do binary dump of the .dat file, you should see the correct resource
name, which is "XalanMessages_1_10D_en_US.res." If you see something like
"..\..\..\..\..\Build\Win32\VC7.1\Debug\Nls\Icu\XalanMessages_1_10D_en_US.res,"
then the resources were built with a newer version of the ICU.
You might also try to debug the code, to see if the ICU returns an
error code, or if the resource bundle pointer is null.
I've debugged the code - line 134 of XalanICUMessageLoader.cpp is failing:
m_localeBundle = ures_open(sPackageName, szLocal , &err);
sPackageName is "XalanMessages_1_10D", szLocal is "en_US" and err comes
back as U_MISSING_RESOURCE_ERROR.
Stepping into the ICU code, it looks to me like u_getDataDirectory is
failing, I think because this line (1351 in putil.c):
path=getenv("ICU_DATA");
returns null.
So, are we required to set the ICU_DATA environment variable to get
xalan to work with ICU? If so, how does this affect other applications
that might be using ICU? Could we simply for xalan to pass the full
path in sPackageName instead?
No, the ICU_DATA environment variable is not required.
Dave
