2

I compiled code(in linux) that make use of printf and I saw that during compile (gcc -c) the symbol stays printf but when I compile and link it (gcc -o) I see that the symbol changes to printf@GLIBC.2.2.5. It also happens with other symbols that are part of glibc.

Does the linker change the symbol so it will only work when linking with one version of glibc and not others?

jww
  • 97,681
  • 90
  • 411
  • 885
roy cabouly
  • 487
  • 4
  • 12
  • 1
    Also see [Versioned Symbols - A New Level of Hell](http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols) and [What do the multiple GLIBC versions mean in the output of ldd?](https://unix.stackexchange.com/q/458659) You may also be interested in [How can I link to a specific glibc version?](https://stackoverflow.com/q/2856438/608639) – jww Jul 14 '19 at 21:06

1 Answers1

2

Does the linker change the symbol so it will only work when linking with one version of glibc and not others?

No.

To understand what's happening here, you need to know about GNU versioned symbols.

With very rare exceptions, GLIBC maintains backward compatibility (older programs continue to run when the version of GLIBC at runtime is the same or newer then the version against which the program was linked).

In case of printf@GLIBC.2.2.5, the printf ABI changed some time before 2002 (GLIBC-2.2.5 was released on 2002-01-20), and hasn't changed since. Your binary will work with any version of GLIBC released since then (for this specific symbol; you may be using other symbols that require newer GLIBC).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • It should be noted that this entire mechanism doesn't actually work as intended, because the version needed to match ABI the object file was compiled with is the one corresponding to the version of headers present at the file the source file was *compiled*, but the version that gets bound is the one that was currentlly default at the time the object file was *linked* into an executable or shared library. These are "often" the same, but can be significantly different if the affected object file is part of a static (archive) library. – R.. GitHub STOP HELPING ICE Jul 14 '19 at 20:24
  • The Right Way the same thing could have been achieved without this problem, and without having symbol versoning hacks in the linker and runtime dynamic linker, is by having the headers define the necessary version-specific redirections so that the one that gets used is always bound at *compile-time* rather than *link-time*. – R.. GitHub STOP HELPING ICE Jul 14 '19 at 20:26
  • `GLIBC_2.2.5` is used because the port (x86-64?) was released first for glibc 2.2.5 (or backported into it, I haven't checked). Old symbol versions which have been superseded before a new architecture launched are dropped because there cannot be any old binaries which use them. – Florian Weimer Jul 15 '19 at 07:09