Bruno Haible <[email protected]> writes: > 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.
Great. > 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: ... Given that the parameter is called --version-script, I think "version-script" would be a better name for the module. > 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. Sounds good. It seems (a) has already been fixed right? I'll prepare a new patch. /Simon
