如果我在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是否有与版本号无关的子名?
编辑:澄清一下,我理解符号链接。让我困惑的是两个编号方案的存在。如果你看一下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的符号链接是令人困惑的…
发布于 2018-05-28 09:38:25
让我困惑的是两个编号方案的存在。
在GNU符号版本控制发明之前,对ABI的任何更改都需要引入一个全新的库版本,并且系统上必须存在两个(或更多)副本。
描述了外部库版本控制,例如here。
随着每符号版本控制(GNU symbol versioning)的引入,外部库版本控制变得完全不必要了:一个库中可以支持多个ABI。
这就是为什么libc.so.6一直停留在版本6(20世纪90年代末)。根本没有理由使用符号链接--这个库可以简单地命名为libc.so.6。但是,使用符号链接并使其指向当前的库版本是很方便的,例如libc-2.27.so。
libstdc++.so也停留在libstdc++.so.6上,但它是不同的:维护多个C++ ABI要困难得多。因此,库中的次要版本会随着每个版本的增加而递增(较新的GCC需要较新版本的libstdc++.so)。
但它们不会更改.so.6部分,因为这样做将需要多个libstdc++.so副本(它们将共享99%的代码)。
https://stackoverflow.com/questions/50514941
复制相似问题