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

[Steinar Bang]

>>>>> "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.