为何无版本后缀的共享库正常，带版本的却出现链接符号缺失？

问题背景 #

之前我把库编译成无版本后缀的libalx-module.so时一切正常，现在改成了带版本的结构（当前版本1.0~b18）：

• 实际库文件：libalx-module.so.1.0~b18
• 符号链接：libalx-module.so.1 → 实际库文件
• 没有纯.so后缀的文件，所有库文件都带版本信息

ldconfig已经正确识别了这些库，但依赖该库的程序在链接阶段失败：编译正常，但找不到库依赖的其他库的符号（尤其是C++符号）。具体表现为：

• 依赖C符号的C程序可以正常编译运行
• C++程序可以正常编译运行
• 依赖C++符号的C程序编译失败，报错类似undefined reference to cv::arcLength或std::__cxx11::basic_string...

环境信息 #

$ uname -a
Linux ADY-debian-11 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
$ gcc --version
gcc (Debian 9.3.0-8) 9.3.0
$ ld --version
GNU ld (GNU Binutils for Debian) 2.34

临时解决方法（已验证有效） #

1. 复制实际库文件生成无版本后缀的.so文件：

   sudo cp libalx-cv.so.1.0~b18 libalx-cv.so
   

2. 将pkg-config文件中Libs.private的依赖项移到Libs中：
   比如修改libalx-cv.pc，把-lm -lstdc++从Libs.private移到Libs。

原因分析 #

这个问题的核心是编译时链接器的行为差异，以及pkg-config中Libs和Libs.private的设计意图：

1. 带版本号的.so.x文件的链接行为
   当链接器使用带版本号的.so.x文件（而非无版本的.so）时，会默认将其视为“运行时共享库”，不会自动传递该库的Libs.private依赖给最终的可执行文件。而无版本的.so是专门给编译时链接用的，链接器会通过它解析完整的依赖链。

2. C vs C++符号的差异
   C符号是无名字修饰的，而C符号有复杂的名字修饰（name mangling）。当你的C程序调用了库中基于C实现的函数时，链接器需要找到C标准库（libstdc++）和OpenCV等依赖库的符号，但这些依赖在Libs.private中，链接器不会自动为C程序引入这些库（C程序默认不会链接libstdc++），所以就出现了符号缺失。而C程序编译时会自动链接libstdc++，所以不受影响。

3. 临时方法为什么有效：

   • 方法1：生成无版本的.so后，链接器会用它来解析完整的依赖链，包括Libs.private中的依赖，自然能找到所有符号。
   • 方法2：把Libs.private的依赖移到Libs后，pkg-config会直接将这些依赖传递给链接器，不管是C还是C++程序，都会链接这些库，符号就不会缺失了。

正确解决方案 #

根据你的需求选择以下方案：

方案1：保留编译时的无版本符号链接（推荐）

在安装库时，为每个带版本的库创建一个无版本的符号链接，用于编译时链接。以libalx-cv为例：

sudo ln -s /usr/local/lib/libalx/libalx-cv.so.1 /usr/local/lib/libalx/libalx-cv.so

这个链接只用于编译阶段，运行时仍然使用带版本的libalx-cv.so.1，既符合共享库版本规范，又能解决链接问题。

方案2：调整pkg-config的依赖声明

如果不想保留无版本的.so文件，就把所有上层可执行文件需要的依赖从Libs.private移到Libs中。修改后的libalx-cv.pc示例：

Name: libalx-cv
Description: The libalx C/C++ library (openCV extension)
URL: https://github.com/alejandro-colomar/libalx
Version: 1.0~b18
Requires: opencv4 libalx-base libalx-gsl
Requires.private:
prefix=/usr/local/
includedir=${prefix}/include/
libdir=${prefix}/lib/
Cflags: -I${includedir} -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L
Libs: -L${libdir}/libalx/ -lalx-cv -lm -lstdc++
Libs.private:

这样pkg-config生成的链接参数会包含-lstdc++等依赖，C程序编译时也会链接这些库，符号就能正常找到。

补充：关于SONAME的说明

SONAME是共享库的运行时标识，和编译时链接器的行为无关。系统加载器（ld.so）会通过SONAME找到对应的库文件，而编译时链接器需要的是无版本的.so文件来解析完整的依赖链，这两者是独立的机制。

内容的提问来源于stack exchange，提问作者alx - recommends codidact