gcc - 非常奇怪的链接器行为

Question

这很奇怪，因为我可以通过删除对 libm 的引用来消除下面的错误。

gcc -o example example.o -Wl -L/home/kensey/cdev/lib -L/usr/lib/x86_64-linux-gnu   -lmysqlclient -lpthread -lz -L/usr/lib/x86_64-linux-gnu -lm -lrt -ldl -lcdev -L/home/kensey/www.tools/gplot-lib -lgplot -L/home/kensey/www.tools/gd1_3ret -lgd -lxml2 -lcurl
/usr/bin/ld: /home/kensey/www.tools/gplot-lib/libgplot.a(set.o): undefined reference to symbol 'floor@@GLIBC_2.2.5'
/usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in DSO /usr/lib/x86_64-linux-gnu/libm.so so try adding it to the linker command line
/usr/lib/x86_64-linux-gnu/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

因此，如果我删除命令的 -lm 部分，就不会收到错误消息。但是，我想知道是否有人知道为什么删除对所需库的引用可以解决此问题。链接器如何知道要查找哪个库？另外 - 有没有办法查询构建的可执行文件并说“您解析了哪个库对“地板”的引用？显然，发生了一些我不明白的事情，这让我很困扰......

Answer 1

对发生的事情的解释非常简单:

1. 您的libgplot.a取决于libm.so ，但顺序为 -lm和-lgplot链接线上是错误的。 链接线上的库顺序确实 matter 。一般来说，系统库( -lpthread 、 -lm 、 -lrt 、 -ldl )应该遵循链接线上的所有其他内容。

2. 当您删除 -lm 时从链接线，libm.so.6仍然被稍后出现在链接行上的某个其他库( libgd 、 libxml2 或 libcurl )拉入链接，因为该库依赖于 libm.so.6 。但现在libm.so.6位于链接线上的正确位置，因此一切正常。

if I put -lm at the end of the link command, listing it as the last library, I do not get the error.

这证实了上述解释。