One of the possible reasons of failure on Linux may be because the
LinuxPlatformUtils.cpp file has been coded to look for shared libraries
specifically (i.e. those ending in .so). If you change the shared libraries
to static libraries, I guess a lot of other changes need to be intoduced in
the platform-specific files to comply to this build structure. Merely
changing the library type may not be enough. Also, it may be useful to
mention that the converter files are found relative to the shared library
(looks for icu/data under the shared library) if you have not defined
ICU_DATA. If you do define ICU_DATA do not forget to include the trailing
slash (or backslash). The documentation is incomplete now, but soon these
details will be included.
- Anupam
===========================================================
Anupam Bagchi
Advisory Software Engineer
Phone: (408)777-5842 Fax: (408)777-5892
XML Development Group, IBM Cupertino, California
Michael Mason <[EMAIL PROTECTED]>@decisionsoft.com on 12/03/99 06:47:17
AM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: xerces-dev mailing list <[EMAIL PROTECTED]>
cc:
Subject: Non-shared libraries and ICU?
I appear to be posting a lot to this list, so I'll try and keep this
brief. Out of CVS, Xerces compiles to a shared .so library (talking
Linux here). I then need to include libxerces.so with an application
when distributing it, and hence users must configure their
LD_LIBRARY_PATH or have access to put the .so in (eg) /usr/lib.
This is possible for a user to mess up[1], so in the past I've linked
against .a versions of XML parser libraries, and just distributed the
resulting executable. I'm now trying to do this with Xerces. Replacing
the final g++ execution of the build process (g++ -DLINUX -shared -fpic
-o libxerces-c1_0.so ...) with a call to "ar" and then to "ranlib"
produces libxerces.a which I can happily link against. When I attempt to
run the binary on another (clean, no Xerces or ICU or anything
installed) machine, it complains with:
The Xerces-C system could not be initialized.
If you are using ICU, then the most likely reason for this failure
is the inability to find the ICU coverter files. [etc]
I didn't think I was using ICU, since in my original runConfigure
invocation I specified the internal transcoder. Also, if I link against
the .so version, copy it to the clean machine, set up my LD_LIBRARY_PATH
and run my executable, it works fine without asking for the ICU files.
Yikes, that wasn't as brief as I'd hoped. Any hints appreciated,
Mike.
[1] Of course, I could be insulting a lot of Linux users here, but on
Windows it's a case of "download, unzip, run" and I'd like the Linux
version to be as easy.
