bug-gnulib
[Top][All Lists]
Advanced

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

Re: shared library symbol exports and versioning


From: Simon Josefsson
Subject: Re: shared library symbol exports and versioning
Date: Mon, 02 Mar 2009 16:07:33 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Bruno Haible <address@hidden> writes:

> 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
>
> if HAVE_LD_VERSION_SCRIPT
> libfoo_la_LDFLAGS += -Wl,--version-script=$(srcdir)/libfoo.map
> else
> libfoo_la_LDFLAGS += -export-symbols $(srcdir)/libfoo.sym
> endif
>
> the maintainer has to keep both libfoo.map and libfoo.sym up-to-date,
> and similarly for doing the versioning through libfoo.map or #defines.
>
> .., except if you had a tool that generates libfoo.map from the #defines
> in the header files, and a tool that generates the libfoo.sym from libfoo.map.
>
> 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?

Good question, something like that seems useful.

However, do you object to installing the original module to gnulib?

I think we can improve the documentation and other tools as appropriate
later on.  The need to share M4 tests of the ld version script feature
exists in several of my projects today, and I'd like to push the patch
and unify my projects in this regard as soon as possible.

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

Except that nobody has implemented that yet.. ;)

/Simon




reply via email to

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