[Expat-discuss] Re: Conflict with two expat shared libraries

[Karl Waclawek]

>>>>>> "Karl Waclawek" <karl at waclawek.net>:
> 
>> After re-reading it I am not sure I understand what you did.
> 
> OK.  I'll try phrasing it differently.
> 
>> Does QLibrary::resolve() use dlopen() and dlsym()?
> 
> Without looking at the code: yes, I think so.  And the functions I
> bound to a function pointer using QLibrary::resolve(), like
> eg. XML_Parse(), are bound to the implementation in the correct
> library.
> 
> For the example below I'll name the system installed expat shared lib
> that fontconfig is using expatA, and my own expat shared lib (with
> an XML_Char of short int size) expatB
> 
> What happened was:
> 
> - The application was linked with expatA, because fontconfig was
>   using it
> - When I linked with expatB, fontconfig started using the API in
>   expatB, and got the error message I described
> - When I removed the linkage to expatB, fontconfig started working
>   again, but my own application no longer could parse XML files
> - When I used QLibrary::resolve() to bind a function pointer to
>   eg. XML_Parse() in expatB, fontconfig worked, but my own
>   application still couldn't parse files
> - When I followed XML_Parse() of expatB, in the debugger, I saw
>   that it got to a place where it called the function
>   XmlGetUtf16InternalEncoding().  And the version of the function
>   that was called, was the version in expatA, and not the version in
>   expatB
> 
> The -Bsymbolic flag used when linking expatB will make the XML_Parse()
> function in expatB, always call the XmlGetUtf16InternalEncoding()
> function residing together with it in expatB, no matter what other
> symbols is available through linkage with other shared libraries.
> 
> Did I succeed in making it clearer, or more confused...? :-)

I think what confused me is that with true dynamic linking the linker
is not involved at all. Obviously, what you are doing is still static
linking, and that is why you had to go to great lengths to disambiguate
the linked symbols.

What I had in mind is to define your own header file (not use expat.h at all).
Declare function pointers and types at the size you need, and define
a LoadExpat and UnloadExpat function which you can use to set and clear
the function pointers at application startup and termination.
dlopen() loads the shared library (libexpatw.so), and dlsym() retrieves
the function pointer for each Expat API member. In Windows these
functions would be called LoadLibrary() and GetProcAddress().

It might be a good idea to create such header files as part of the
Expat distribution. They could be called expatdyn.h and expatdynw.h for
8 bit and 16 bit characters.

Karl