Re: Linker scripts

Jonathan Wakely via Gcc-help <[email protected]> Sat, 17 Jan 2026 09:33:11 +0000
Newsgroups gmane.comp.gcc.help
Message-ID <CAH6eHdQyA6c4x+L7mri1hYW=8R54dcL3S2NhLiVY+Uq5dmjGMw@mail.gmail.com>
On Sat, 17 Jan 2026 at 00:41, Gordon Messmer via Gcc-help <
[email protected]> wrote:
>
> In order to improve RPM dependency generation, I'm proposing that the
> Fedora project more actively encourage library developers to use
> versioned symbols.
>
> In reviewing the documentation, I've realized that there is an option
> whose implications I'm not sure I understand. The GNU Linker manual
> (https://sourceware.org/binutils/docs-2.38/ld.pdf) provides an example
> on paged numbered 84:
>
> VERS_1.2 {
>   foo2;
> } VERS_1.1;
>
> And it describes that node as, "the version script defines node
> ‘VERS_1.2’. This node depends upon ‘VERS_1.1’."
>
> What is the practical difference between that and a node that does not
> depend on VERS_1.1? as in:
>
> VERS_1.2 {
>   foo2;
> };
>
> What does "depends upon" mean in this context? If there is a difference
> in the resulting shared library, I don't see it.


The binutils list is probably a better place to ask about the linker.

Conceptually, it means that all symbols from VERS_1.1 are inherited by
VERS_1.2, so that both sets of symbols are exported. This means that a
library using VERS_1.2 should be backwards compatible, and usable by an
application that needs VERS_1.1.

I'm less sure what this means practically, in terms of the actual binaries,
and how it differs from just exporting both VERS_1.1 and VERS_1.2 with no
inheritance from one to the other. I think it affects which symbol gets
bound to by default when linking to a library that exports both foo@VERS_1.2
and foo@VERS_1.1.

If VERS_1.2 depends on VERS_1.1 then the symbol from the newer version will
be the default, recorded as foo@@VERS_1.2 and that will be used when
linking to the library. If there's no dependency between the versions, I
think you would get an error when linking to the library, unless references
to foo were disambiguated at the assembly level by referencing foo@VERS_1.2
explicitly.

I don't know if there are more effects, or if it's just a way for the
linker to know which symbol is "newest" in a chain of dependent symbols, so
that it can use @@ instead of @ for specifying the default version to use
when linking to the library.