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

[Karl Waclawek]

----- 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?
> 
> Yes.
> 
>> 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?

Karl