Question

如果我在Docker的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

似乎libc被编号为6和2-23。为什么有两个版本号？

NB libc是（特异性地）可执行的并且运行它给出了

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.

所以libc.so.6令人惊讶。 libc [或者确切地说，glibc]是否具有与版本号无关的sonames？

编辑：澄清一下，我理解了符号链接。令我困惑的是存在两种编号方案。如果你看一下，例如libstdc ++，你找到了

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

将foo.so.6作为foo.so.6.0.19的符号链接是有道理的。将foo.so.6作为foo-2.23.so的符号链接令人困惑......

Answer 1

令我困惑的是存在两种编号方案。

在GNU符号版本控制发明之前，对ABI 所需的任何更改引入了全新版本的库，并且必须在系统上存在两个（或更多）副本。

描述外部库版本控制，例如here

随着每符号版本控制（GNU符号版本控制）的引入，外部库版本控制变得完全：单个库中可以支持多个ABI。

这就是为什么Get-AzureRmVirtualNetwork | select Name |out-file $filePath -Append Get-AzureRmNetworkInterface | Select-Object -Property Name, @{Name="VMName";Expression = {$_.VirtualMachine.Id.tostring().substring($_.VirtualMachine.Id.tostring().lastindexof('/')+1)}} |out-file $filePath -Append永远存在于版本6（20世纪90年代末）的原因。没有任何理由可以使用符号链接 - 库可以简单地命名为libc.so.6。但是，使用符号链接方便并使其指向当前库版本，例如， libc.so.6。

libc-2.27.so 也卡在libstdc++.so，但却不同：维护多个C ++ ABI要困难得多。因此，库不断增加每个GCC版本的次要版本（较新的GCC需要较新版本的libstdc++.so.6）。

但是他们不会更改libstdc++.so部分，因为这样做需要多个.so.6份副本（共享99％的代码）。

为什么libc有两个版本号（在Ubuntu上）？

1 个答案: