C++ 为什么要级联共享对象链接
c++ why cascade shared object linkage
在我的lib目录中,我看到大多数共享对象链接都是级联的。例如:
libctest.so.1.0 -> libctest.so.1
libctest.so.1 -> libctest.so
我知道libctest.so
的链接是使编译标志-lctest
工作,但是libctest.so.1
有什么意义?
我认为您以与通常显示方式相反的顺序编写了 filnames,您将有 3 个文件
libctest.so.1.0 (library file)
libctest.so.1 -> libctest.so.1.0 (symlink to the libctest.so.1.0 file)
libctest.so -> libctest.so.1 (symlink to the libctest.so.1 symlink
它是一种版本控制方案。
库的特定版本/安装具有完整的文件名,例如libctest.so.1.0
,嵌入到这个库中的是SONAME,一个库的逻辑名称,例如libctest.so.1
也用作实际文件的符号链接。
链接可执行文件时,库 SONAME 将添加到可执行文件中,因此在运行时可执行文件将查找文件名libctest.so.1
。约定是让库的 SONAME 保持相同,只要它向后兼容,并在引入向后不兼容的 ABI 更改时更改它。
正如您所说,当您进行链接时,链接器将查找lib*.so
。
这样,链接到libctest.so.1
的可执行文件(或其他库(可以在升级libctest
时保持不变。因此,当libctest版本1.1发布时,您可能有以下文件:
libctest.so.1.1
libctest.so.1 -> libctest.so.1.1
libctest.so -> libctest.so.1
可执行文件仍然尝试查找 libctest.so.1,因此在升级库时可以保持不变。该库必须编写,以便向后兼容才能在实践中工作。
如果您发布一个新的向后不兼容的库,约定是更改该库的 SONAME,因此您最终会得到例如
libctest.so.2.0
libctest.so.2 -> libctest.so.2.0
这支持在系统上安装多个不兼容版本的库,如果不同的可执行文件需要该库的不同版本。
这些数字都是关于版本控制的。这意味着您可以轻松地同时安装库的多个版本,并且与特定版本链接的应用程序将使用该版本(因为链接器解析符号文件系统链接(。
相关文章:
- CMake-按正确顺序将项目与C运行时对象文件链接
- 我可以将一个用clang c++11编译的对象与另一个用c++17编译的对象链接起来吗
- 返回的指向C++对象的链接是什么样的
- C++ 创建包含链表和字符串的对象的链接列表时出错
- 返回一个带有 std::move 的对象并链接函数
- 链接列表在 cpp 中包含不同的对象类
- 链接时,不同静态库中的同一对象文件
- 通过 Gazebo 世界插件将静态对象附加到机器人链接
- 共享对象、符号、C/C++ 库链接和加载
- 尝试使用 extern "C" 调用 C 中的C++方法,得到"undefined reference to"对象的链接器错误
- 仅为从某种语言编译的对象添加链接库?
- C++ 为什么要级联共享对象链接
- 从最基本的Qt应用程序重新链接对象 - 链接器错误
- Natty Narwhal和Oneiric Ocelot之间共享对象链接的差异
- 静态成员对象链接错误
- 与模板函数中的局部派生对象链接错误
- 使用Cuda对象链接与Cmake
- Qt元对象链接器问题
- 使用MVP,如何从与同一模型对象链接的另一个视图创建视图
- 创建一个简单的"hello world"并将其与 2 个预编译对象链接在一起