Re: shared library symbol versioning

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> So here we have the classical dilemma between use of advanced GNU tools
> and glibc features, vs. portability.
>
> The portable way to do symbol versioning is through the include file.
> In libgettextpo I have this declaration:
>
>   #define po_file_read po_file_read_v3
>   extern po_file_t po_file_read (...);
>
> The first version of the function was called po_file_read, the second one
> po_file_read_v2. The current one is po_file_read_v3.
>
> The implementation file has to be careful to define all 3 functions, and
> invoke the right ones internally - but that's something you would have to
> worry about as well when using the linker script approach.
>
> How portable is your linker script approach? I.e. what is the outcome if
> the library defines 3 different versions of 'po_file_read' and either
>   a) the library is installed statically (--disable-shared), or
>   b) the library is installed on a system like MacOS X, HP-UX or mingw?

I won't dispute that ELF version symbol scripts are overrated because
they aren't portable.  But they do provide some features, and together
with a scheme like you suggest you get more complete cross-platform
versioning.

One feature that LD version script provides, that your approach doesn't
provide, is that Debian's packaging tools to resolve dependencies and/or
facilitate future upgrades apparently works better.  I'm not familiar
enough to know exactly _what_ they are using versioned symbols for to
explain this more though.  Other distributions than Debian have also
requested ELF version scripts from my libraries, so it seems to be
common.  Most likely someone else on this list knows more about this
than me.  Help?

/Simon