Re: shared library symbol exports and versioning

[Simon Josefsson]

Bruno Haible <address@hidden> 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