2

If I run this in Docker's ubuntu:latest:

root@4304dfbfa661:/# ls lib/x86_64-linux-gnu/libc* -l
-rwxr-xr-x 1 root root 1868984 Jan 15 02:51 lib/x86_64-linux-gnu/libc-2.23.so
lrwxrwxrwx 1 root root      12 Jan 15 02:51 lib/x86_64-linux-gnu/libc.so.6 -> libc-2.23.so

It seems that libc is numbered as both 6 and 2-23. Why are there two version numbers?

NB libc is (idiosyncratically) executable and running it gives 

root@4304dfbfa661:/# ./lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu GLIBC 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.

So it's the libc.so.6 that's surprising. Does libc [or to be precise, glibc] have sonames that are unrelated to the version numbers?

Edit: to clarify, I understand the symlink. What confuses me is the existence of two numbering schemes. If you look at e.g. libstdc++, you find

lrwxrwxrwx 1 root root     19 Sep 11  2017 ./usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.19
-rwxr-xr-x 1 root root 995840 Aug  1  2017 ./usr/lib64/libstdc++.so.6.0.19

Having foo.so.6 as a symlink to foo.so.6.0.19 makes sense. Having foo.so.6 as a symlink to foo-2.23.so is confusing...

Mohan
  • 7,302
  • 5
  • 32
  • 55
  • `/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.23.so` means that 'libc.so.6' is a symlink to 'libc-2.23.so'. ... (The run time version is always 'libc.so.6', no matter of the version.) .... Please have a look at other libraries : Most are present as one or two symlink´s to the main library. – Knud Larsen May 24 '18 at 18:11
  • @Knud Larsen >The run time version is always 'libc.so.6', no matter of the version That's what I'm trying to understand... what determines the run time version? When does it change? Cf. edit to q. – Mohan May 24 '18 at 18:30
  • As 'libc.so.6' is a symlink to e.g. 'libc-2.23.so' it will change e.g when you upgrade the OS. .... Example Ubuntu 18.04 : `libc.so.6 -> libc-2.27.so` – Knud Larsen May 24 '18 at 18:58
  • @Knud Larsen Yes, understood, but _why_ is the 2.23 version numbering scheme completely distinct from the soname numbering scheme? Contrast libstdc++ where there is only one numbering scheme... MAJOR.MINOR.PATCH. – Mohan May 24 '18 at 19:25
  • `libstdc++` has an equal naming : Example, the libstdc++ gcc version 5.x.x → `libstdc++.so.6 -> libstdc++.so.6.0.21`. ... A different naming was as long back as gcc-3.3.6 : `libstdc++.so.5 -> libstdc++.so.5.0.5` – Knud Larsen May 24 '18 at 20:21
  • In both cases the reason is the same. All C applications depend on 'libc.so.6'. All C++ applications depend on 'libstdc++.so.6'. Then older applications can run on a newer OS. ( Unless they have special dependencies.) – Knud Larsen May 24 '18 at 20:33
  • 1
    Conventions etc. http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html **,,, ,,,** http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/index.html ... But if you are the author, any naming is your decision. Can even be built as `libname.so` and nothing else. Glibc : You can ask https://www.gnu.org/software/libc/ – Knud Larsen May 25 '18 at 07:43

2 Answers2

4

What confuses me is the existence of two numbering schemes.

Before the invention of GNU symbol versioning, any change to the ABI required that an entirely new version of the library was introduced, and two (or more) copies had to be present on the system.

External library versioning is described e.g. here.

With the introduction of per-symbol versioning (GNU symbol versioning), external library versioning became completely unnecessary: multiple ABIs could be supported in a single library.

This is why libc.so.6 stayed at version 6 since forever (late 1990s). There is no reason to have a symlink at all -- the library could simply be named libc.so.6. However, it is convenient to have the symlink and have it point to current library version, e.g. libc-2.27.so.

The libstdc++.so is also stuck at libstdc++.so.6, but it is different: maintaining multiple C++ ABIs is much more difficult. So the library keeps incrementing minor version with each GCC version (newer GCC requires newer versions of libstdc++.so).

But they don't change the .so.6 part because doing so would require having multiple libstdc++.so copies (which will share 99% of the code).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
0

History about the two numbering schemes:

Linux libc was forked from FSF's glibc in 1980s, and turned back to glibc again in 1997-98 to correct the 'strategic mistake'.

Then:

The version numbers were a minor problem: The GNU/Linux guys had already reached 5.4.47, while FSF was just hitting 2.0. They probably pondered for about a millisecond asking Stallman to make his next version 6.0 for their benefit. Then they laughed, said "This is Stallman we're talking about, right?", and decided out-stubborning Richard was not a wise idea. So, the convention is that Linux libc version 6.0 is the same as glibc 2.0.

details here

So, libc.so.6 is just something like a conversional name.

Tomas
  • 56
  • 6