linux - 当库存在时，是什么导致 gcc 中出现找不到库错误？

Question

在重新格式化/重新安装 Linux 之后，我正在尝试构建一些曾经有效的代码。我不确定如何调试此类错误。虽然我想知道下面这段代码有什么问题，但我还想知道如何找出问题所在——要寻找的线索是什么？

$ more test.c

void main() {}

$ gcc test.c
<works>

$ gcc test.c -lboost_system
/usr/bin/ld: cannot find -lboost_system
collect2: error: ld returned 1 exit status

$ gcc test.c -lboost_filesystem
/usr/bin/ld: cannot find -lboost_filesystem
collect2: error: ld returned 1 exit status

$ locate boost_filesystem
/usr/lib64/libboost_filesystem.so.1.58.0

$ locate boost_system
/usr/lib64/libboost_system.so.1.58.0

$ uname -a
Linux mycomputer 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ sudo dnf list installed | grep boost
boost-date-time.x86_64                 1.58.0-9.fc23            @updates        
boost-filesystem.x86_64                1.58.0-9.fc23            @updates        
boost-iostreams.x86_64                 1.58.0-9.fc23            @updates        
boost-system.x86_64                    1.58.0-9.fc23            @updates        
boost-thread.x86_64                    1.58.0-9.fc23            @updates        

更新 @Kenny 建议我寻找开发包。它没有安装。 dnf install boost-devel 它已安装。然后，当我运行 gcc test.c -lboost_system 时，它起作用了。但是，我仍然不知所措。更改了什么机制/文件/设置以使其工作？当我运行 locate boost_system 时，我仍然得出同样的结果。我意识到该包安装了一些头文件，但我的 test.c 中没有提到 boost。

Answer 1

在 Debian 和 Debian 派生的发行版中，例如 Ubuntu，库包通常分为二进制包和开发包。

库二进制包通常包含共享库文件及其完整的三位数版本名称 ( libfoo.so.1.2.3 ) 以及指向它的一个和/或两位版本名称的符号链接(symbolic link) ( libfoo.so.1.2 , libfoo.so.1 )指向第一个。这个一位或两位数版本的文件是它在运行程序时实际寻找的文件(谷歌搜索 ELF SONAME 以获取详细信息)。

库开发包通常包含头文件 (*.h) 和一个没有任何版本号的符号链接(symbolic link)到共享对象 (libfoo.so)。可选地，可能还有一个静态库文件 ( libfoo.a )。

现在，当您编译程序并添加 -lfoo 选项时，链接器将查找实际上是指向 libfoo.so 的符号链接(symbolic link)的文件 libfoo.so.1.2.3，并将该文件用作共享库。

这就是为什么这个符号链接(symbolic link)在 dev 包而不是 bin 包中的原因:因为共享库有一个带有 libfoo.so.1 或 libfoo.so.1.2 的 SONAME，运行时程序不需要 libfoo.so 符号链接(symbolic link)。它仅用于构建。

PS:查看包中的文件不要使用 locate 。使用 dpkg -L libboost-filesystem-dev 。