bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared library symbol versioning


From: Bruno Haible
Subject: Re: shared library symbol versioning
Date: Mon, 2 Mar 2009 13:56:11 +0100
User-agent: KMail/1.9.9

Simon Josefsson wrote:
> > Or is it about allowing multiple versions of the same symbol to exist
> > in the same shared library, something which is supported only by glibc
> > and Solaris [2]?
> 
> Yes, that is one reason.
> 
> > I'm asking because linker scripts only work with GNU ld (I guess).
> 
> Yes, I think so.
> 
> Further, shared library versioning can be useful when maintaining
> packages in GNU/Linux distributions, and it seems people in Debian
> prefers that shared libraries always use versioning.

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?

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]