[Expat-discuss] Re: Conflict with two expat shared libraries
karl at waclawek.net
Tue Oct 19 20:02:34 CEST 2004
----- Original Message -----
From: "Steinar Bang" <sb at dod.no>
Sent: Tuesday, October 19, 2004 1:54 PM
>>>>>> "Karl Waclawek" <karl at waclawek.net>:
>> However, should it not work anyway?
>> When the ELF library is loaded, aren't the links to these functiones
>> like XmlGetUtf16InternalEncoding resolved already (at compile time),
>> at least for those calls that are internal to the library?
> Nope. But the -Bsymbolic flag effectively achives this effect (though
> in a different manner, see below).
>> Or are they still left open for late binding?
>> Would that late binding then happen when dlopen() is called, or even
>> later, when dlsym() is called?
> That's what I experienced.
I did a quick readup, and I found that contray to Windows Dlls
ELF libraries share a global namespace for all their symbols.
This together with late binding for internal links obviosuly explains it.
> However, using the -Bsymbolic flag when creating the shared library
> solved my problem. What it does (for listing googleable terms), is to
> is set the DT_SYMBOLIC dynamic entry. This is interpreted to search
> the module itself, and its immediate dependencies, instead of doing a
> global search.
I saw that flag mentioned as well. Supposedly it is not well supported.
Hhmm, would it not be better then to find a way to control
which symbols are exported from within Expat? In other words,
isn't there a design issue with Expat?
More information about the Expat-discuss