Simon,
> However, do you object to installing the original module to gnulib?
Now that you have shown that it provides access to functionality that
libtool does not provide portably, I don't object.
But I would find it useful to revise the doc and the module name
1) in order to clarify that it's about symbol versions, not about controlling
the linking process. The GNU ld documentation describes these two file
formats called "linker scripts" and "version scripts" like this:
--------------------------------------------------------------------------
3 Linker Scripts
****************
Every link is controlled by a "linker script". This script is written
in the linker command language.
The main purpose of the linker script is to describe how the
sections in the input files should be mapped into the output file, and
to control the memory layout of the output file. Most linker scripts
do nothing more than this. However, when necessary, the linker script
can also direct the linker to perform many other operations, using the
commands described below.
The linker always uses a linker script. If you do not supply one
yourself, the linker will use a default script that is compiled into the
linker executable. ...
--------------------------------------------------------------------------
The format of the version script commands is identical to that used
by Sun's linker in Solaris 2.5. The version script defines a tree of
version nodes. You specify the node names and interdependencies in the
version script. You can specify which symbols are bound to which
version nodes, and you can reduce a specified set of symbols to local
scope so that they are not globally visible outside of the shared
library.
--------------------------------------------------------------------------
2) in order to clarify the purposes of the module. No one comes to gnulib
saying "I want to use a linker script". The developer says either
(a) "I want to reduce the number of possible clashes of my library with
other libraries", or
(b) "I want to be able to make incompatible changes to the API of my
library", or
(c) "I want dpkg-shlibdeps to produce good results for packages that use
my library".
IMO the doc should be centered around these questions. There's enough to
say about each of the three points:
(a) talk about the three approaches: ld version scripts,
libtool -export-symbols and gcc -fvisibility,
(b) versioning at the include file level and via ld version scripts,
(c) explain how dpkg-shlibdeps works.
For point (a), we already have the file visibility.texi, but it is
incomplete: it does not talk about libtool -export-symbols.
Bruno
