[Expat-discuss] Conflict with two expat shared libraries

[Steinar Bang]

Platform: Intel Pentium M,
	  debian sarge (testing/unstable),
	  libexpat1 1.95.6-8,
	  libqt3c102-mt,
	  fontconfig 2.2.3-1

After an apt-get dist-upgrade, my own Qt application got a strange
error.  It printed out the following lines to the console
	Fontconfig error: line 1: unknown encoding
	Fontconfig error: Cannot load default config file
and started up with a strange-looking font called "Arioso", when what
I expected was Helvetica.

I traced this down to the application being linked with two separate
expat shared libraries, the one native to debian sarge, used by
fontconfig to read its configuration files, and a different version
used with my application.

The problem is that the native expat on debian sarge is compiled to
use single width char with UTF-8, while the version used by my
application is compiled to use unsigned short with UTF-16 (to be a
best fit to QString and QConstString).

As I see it, I have the following paths open to me:
 1. convert my application to use the UTF-8 API, and use the native
    shared lib for everything
 2. create an extra header file, which prefixes all symbols of my
    application's version of expat with some "prefix_"
 3. manually edit my application's version of expat, and add "prefix_"
    to all non-static symbols

Does anyone have any better ideas?  I'm open to all suggestions.

I have already tried alternative 1, and I know that works.  My
application started up without the fonconfig error messages, and using
Helvetica as its font.  But this approach will give me a serious
performance hit when parsing big XML files, because of the added
string copying and UTF-8 to UTF-16 conversion.

I'd rather avoid alternative 3 if I can.  I prefer to keep the expat
source in local CVS as pristine as possible, to ease upgrades.

I'm currently trying to do 2. with the help of a perl script.  But
according to "nm -op" there's a lot of exported symbols in an expat
shared lib... so far I haven't been successful in eliminating the
error. 

One thing I tried, that didn't work out, was to make my application's
version of expat be a static lib, with the .o files compiled with
-fPIC.  That just made the shared library linked with expat (my
application consists of a lot of shared libraries) export the symbols
that conflicted with the native expat.

As I said, I'm open to suggestions!

Thanx!


- Steinar