Re: Problem with exporting local symbols

[Ralf Wildenhues]

Hi Ralf,

* Ralf Hoffmann wrote on Fri, Jun 10, 2005 at 02:02:01PM CEST:
> 
> I have a problem about symbol collisions in shared librarys. I currently
> porting the build process of a shared library to libtool and the build
> itself works so far.
> The library uses a modified zlib implementation so the final library
> contains zlib symbols. In the old build process the linker was called
> with -version-script option using a script marking some symbols global
> and all other (include the zlib symbols) local.

> Since libtool doesn't offer this option I used the option
> -export-symbol-regex so only the global symbols are exported at all.
> But the result doesn't work correctly. Obviously the other symbols are
> not defined local but are removed from the symbol table. However, the
> dynamic loader messes up these symbols when an application is linked
> with this library and the system wide zlib library.

This is a problem.  Libtool only uses a version script in some cases,
and then obviously only on those systems/linkers that support it.
It /could/ use versioned symbols more often (and I guess it could
provide this option to the user, "portable" to GNU/Linux and Solaris).
However, for the remaining cases that still would not solve your
problem.

If you can limit yourself to GCC and ELF systems, you can play with the
visibility switches and/or pragmas.  For win32, not exporting would work
as well, and I bet AIX non-brtl can do such thing, too (I just don't
know how).

But if your portability is to extend beyond that, I would not know how
to do it.  In any case static linking will break.

Note that most of the suggested changes break the API of your library.

> Only explicitly defining the symbols local prevents the linker from
> choosing the wrong symbols but it looks like the linker option
> "-version-script" only exists in GNU ld and solaris ld so this is not
> very portable.

Solaris has symbol versioning but it works somewhat differently than
GNU.  See Drepper's dsohowto for some good information about that.

> Do you know of any other solution than renaming all symbols of the own
> zlib verion?

If they are not many, that is bound to be the easiest choice after the
visibility stuff.  And of course by far the most portable.

Regards,
Ralf