Why does libc have two version numbers (on Ubuntu)? - libc

Question

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...

Answer 1

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).

Answer 2

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.