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
