We could (should, I think) also skip this initialization code if the parser is not linked with ICU. No new build options should be needed - a run-time test should be fine. This would at least narrow the problem, and eliminate it entirely for configurations that are not using ICU. -- Andy Mike Mason wrote > 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. > Rahul Jain replied > 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. [...] > I am all for adding options to makefile(s) to build Xerces-C in different > ways as long as these are non-breaking changes. -- Andy
