Using a linker version script

Using a linker version script

[Ludovic Courtès]

Hello,

The patch at [0] makes it so that a linker version script (info "(ld)
VERSION") is used for `libguile' on platforms that support it (GNU and
Solaris).

Comments welcome!

Ludo'.

[0] http://git.savannah.gnu.org/cgit/guile.git/commit/?id=9af080f7206dccffb91409529fff74e6554f2385

Re: Using a linker version script

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> The patch at [0] makes it so that a linker version script (info "(ld)
> VERSION") is used for `libguile' on platforms that support it (GNU and
> Solaris).
>
> Comments welcome!

Hi Ludo,

I looked at the ld doc, but that didn't make it obvious what the
benefit of this is; could you explain?

Also, does having this script make it any harder to remove something
from the API in future (e.g. by changing its declaration from SCM_API
to SCM_INTERNAL)?

Thanks,
        Neil

Re: Using a linker version script

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> I looked at the ld doc, but that didn't make it obvious what the
> benefit of this is; could you explain?

The main advantage is that executables/libraries that use versioned
symbols include the required version in their symbol table:

  $ objdump -T guile | grep scm_
  0000000000000000      DF *UND*  0000000000000000  GUILE_2.0   scm_shell
  0000000000000000      DF *UND*  0000000000000000  GUILE_2.0   scm_boot_guile

This allows the dynamic linker to make sure the required version of each
symbol is available.

It also makes it possible to provide two versions of the same symbol,
e.g.:

  SCM scm_from_string (const char *)                --> GUILE_2.0
  SCM scm_from_string (const char *, scm_t_handler) --> GUILE_2.1

Applications that were compiled against libguile 2.0 will keep using the
GUILE_2.0 version of the function, while those compiled against 2.1 will
use the GUILE_2.1 version.

Technically, defining multiple versions of a given symbol is achieved
using the `.symver' GNU as directive:

   __asm__ (".symver scm_from_string_v2_0,scm_from_string@GUILE_2.0");
   __asm__ (".symver scm_from_string,scm_from_string@GUILE_2.1");

> Also, does having this script make it any harder to remove something
> from the API in future (e.g. by changing its declaration from SCM_API
> to SCM_INTERNAL)?

No.  Symbol versions and available symbols are managed manually.

Thanks,
Ludo'.

Re: Using a linker version script

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> It also makes it possible to provide two versions of the same symbol,
> e.g.:
>
>   SCM scm_from_string (const char *)                --> GUILE_2.0
>   SCM scm_from_string (const char *, scm_t_handler) --> GUILE_2.1
>
> Applications that were compiled against libguile 2.0 will keep using the
> GUILE_2.0 version of the function, while those compiled against 2.1 will
> use the GUILE_2.1 version.
>
> Technically, defining multiple versions of a given symbol is achieved
> using the `.symver' GNU as directive:
>
>    __asm__ (".symver scm_from_string_v2_0,scm_from_string@GUILE_2.0");
>    __asm__ (".symver scm_from_string,scm_from_string@GUILE_2.1");

That sounds very cool.  But given that we try to consider non-GNU
platforms too, will it really give us more options than we have at
present?

Regards,
        Neil

Re: Using a linker version script

[Ludovic Courtès]

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> It also makes it possible to provide two versions of the same symbol,
>> e.g.:
>>
>>   SCM scm_from_string (const char *)                --> GUILE_2.0
>>   SCM scm_from_string (const char *, scm_t_handler) --> GUILE_2.1
>>
>> Applications that were compiled against libguile 2.0 will keep using the
>> GUILE_2.0 version of the function, while those compiled against 2.1 will
>> use the GUILE_2.1 version.
>>
>> Technically, defining multiple versions of a given symbol is achieved
>> using the `.symver' GNU as directive:
>>
>>    __asm__ (".symver scm_from_string_v2_0,scm_from_string@GUILE_2.0");
>>    __asm__ (".symver scm_from_string,scm_from_string@GUILE_2.1");
>
> That sounds very cool.  But given that we try to consider non-GNU
> platforms too, will it really give us more options than we have at
> present?

It will give us more options on GNU (and possibly Solaris) but not on
the other platforms.  So that won't affect our policy of not breaking
the ABI during a stable series.

On GNU and Solaris, we may be able to reduce the number of applications
that have to be recompiled when a new major version comes out by:

  - having per-symbol binary compatibility info, as opposed to Libtool's
    coarse-grain `-version-info'.

  - providing older versions of symbols that have changed.

I see it essentially as an additional "safety net", and something that
GNU/* distribution maintainers will appreciate.

Section 3.3 of [0] contains a discussion of this.

Thanks,
Ludo'.

[0] http://people.redhat.com/drepper/dsohowto.pdf

Re: Using a linker version script

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> It will give us more options on GNU (and possibly Solaris) but not on
> the other platforms.  So that won't affect our policy of not breaking
> the ABI during a stable series.
>
> On GNU and Solaris, we may be able to reduce the number of applications
> that have to be recompiled when a new major version comes out by:
>
>   - having per-symbol binary compatibility info, as opposed to Libtool's
>     coarse-grain `-version-info'.
>
>   - providing older versions of symbols that have changed.
>
> I see it essentially as an additional "safety net", and something that
> GNU/* distribution maintainers will appreciate.

OK, many thanks for explaining all that.  I'm happy that this is
useful now.

> Section 3.3 of [0] contains a discussion of this.

That paper is so verbose that I find it difficult to read!  But thanks
for the reference anyway; I know where to go now if I want to know
every detail of dynamic linking.

Regards,
        Neil