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

[Steinar Bang]

>>>>> "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...? :-)