[Top][All Lists]

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

Re: shared library symbol exports and versioning

From: Bruno Haible
Subject: Re: shared library symbol exports and versioning
Date: Mon, 2 Mar 2009 15:45:29 +0100
User-agent: KMail/1.9.9

Simon Josefsson wrote:
> 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.

... at the cost of maintaining the same information twice. In the doc
patch where you propose

libfoo_la_LDFLAGS += -Wl,--version-script=$(srcdir)/
libfoo_la_LDFLAGS += -export-symbols $(srcdir)/libfoo.sym

the maintainer has to keep both and libfoo.sym up-to-date,
and similarly for doing the versioning through or #defines.

.., except if you had a tool that generates from the #defines
in the header files, and a tool that generates the libfoo.sym from

This rises a question regarding libtool: Could libtool also accept
GNU ld style .map files as input for the -export-symbols option, and
if the linker is not GNU ld, process the .map file itself, like it would
normally process a .sym file?

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

Indeed, it appears that they have a program 'dpkg-shlibdeps' that, after
a package has been built, determines the minimal required version of each
dependency (by looking at the symbol lists) and stuffs this information into
the Debian specific packaging files. But such a tool should also work when
the versioning is done by appending _v2, _v3, etc. to the symbol names.


reply via email to

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