Re: shared library symbol exports and versioning

[Bruno Haible]

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?

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

Bruno