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建议我寻找devel包。它没有安装。 dnf install boost-devel已安装。然后，当我运行gcc test.c -lboost_system时，它可以工作。但是，我还是不知所措。更改了什么机制/文件/设置以使其工作？当我运行locate boost_system时，我仍然提出相同的问题。我意识到该软件包安装了一些头文件，但我的test.c没有提到它的提升。

Answer 1

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

库二进制包通常具有共享库文件及其完整的三位数版本名称（libfoo.so.1.2.3）以及带有一位和/或两位数版本名称的符号链接（ libfoo.so.1.2，libfoo.so.1）指向第一个。这个一位或两位数版本的文件是运行程序时实际查找的文件（google for ELF SONAME了解详细信息）。

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

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

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

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

当库存在时，是什么导致gcc中找不到库的错误？

1 个答案: