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

[Karl Waclawek]

----- Original Message ----- 
From: "Steinar Bang" <sb at dod.no>
Sent: Sunday, October 17, 2004 5:57 PM

>>>>>> "Karl Waclawek" <karl at waclawek.net>:
> 
>> 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.
> 
> Actually, using -Bsymbolic to create expatB was the simple approach.
> Dynamically linking, and binding _all_ exported symbols would have
> been a lot more work.  And the problem symbols, such as
> e.g. XmlGetUtf16InternalEncoding(), I couldn't have done anything
> about, without rewriting my version of expat to use function pointers,
> and dynamic binding.
> 
>> 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.
> 
> It won't work on ELF-architectures, without rewriting the expat
> internals to use function pointers, with explicit binding to the
> library they will be a part of.  Use the name of the shared library
> they'll end up in, as a string constant, or something.
> 
> If your background is Win32, note that a big difference between DLLs
> and ELF shared libraries, is that on ELF all global references are is
> exported.  That is, all global references except static functions, and
> variables, which aren't exported outside of the compilation unit (if
> we're talking C and C++).
> 
> Ie. it's like if you have __declspec(dllexport) on all functions.


You guessed right, my background is Win32, and I didn't know that
in ELF libraries all global references are exported.

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

I admit, I don't understand much about how linking works on Linux,
and not that much about it in general.

Karl