Hi Michael,
> After some more fiddling, I've come to these conclusions:
>
> The code in the Linux version of XMLPlatformUtils::platformInit()
> explicitly searches for the environment variable LD_LIBRARY_PATH, and
> panics if it's not set. It then searches all the directories specified
> in LD_LIBRARY_PATH, and panics if it can't find "libxerces-c1_0.so"
> (that string is constructed dynamically from the current version of the
> Xerces library). It then sets XMLPlatformUtils::fgLibLocation to the
> location of the discovered .so library.
>
> This behaviour seems a bit weird to me, because if my system can't find
> the .so (either by LD_LIBRARY_PATH or having it in /lib or similar) it
> won't even run my executable, so the code in platformInit() won't get
> run either. I came across this because I wanted to put an executable
> behind Apache and use it for CGI, and couldn't persuade it not to panic,
> even though the .so was in /lib. A fix is to hack platformInit() so it
> just creates its mutex and then returns.
>
I agree that current code is broken if the Xerces-C shared libarary is
installed in the system library directories, which are looked up
by default by the loader.
Also, I agree the current code will not work if you use a static version
of the Xerces-C libarary in your application.
> I figure if I keep this hack and then create a static library, I should
> be able to link against it and avoid having to distribute any separate
> libraries.
>
> Can anyone explain the rationale behind this behaviour, and comment on
> whether I'm doing the right thing? If I am, should I go about creating a
> patch to add a "static" option to the runConfigure script (or somewhere
> else more appropriate) and submit it to the list?
Your hack will work as long as you do not use ICU as a transcoding service.
More specifically, you can still use ICU as long as you explicitly define
where the transcoding converter files are located via the environment
variable ICU_DATA, and not rely on the 'discover yourself where the
converter files are' mechanism.
The default 'discover yourself where the converter files' logic in Xerces-C
relies on them being located relative to the location of the Xerces-C
shared library and hence the current code. This location of the library is
stored in the XMLPlatformUtils::fgLibLocation variable.
Currently, fgLibLocation is only used to figure out where the converter
files are. Never know, what else it might be used for in future.
I am all for adding options to makefile(s) to build Xerces-C in different
ways as long as these are non-breaking changes. The other issues we have
to address while talking about static Xerces-C libraries are:
* what value will be assigned to fgLibLocation
* what is the fallback logic of discovering the ICU converter files.
These issues are only relevant in the context of the using ICU and become
non-issues if native transcoding option is used.
Coming back to fixing the problem of 'panic' when the dynamically
loaded Xerces-C library is installed in system default places like
'/lib' and '/usr/lib', we should augument the code to look into these
directories in addition to the values specified for LD_LIBRARY_PATH.
A still better solution is to figure out how we can find out the
loaded libraries via a system call (like we currently do under Solaris, AIX
and HPUX).
rahul
