非常奇怪的链接器行为

这很奇怪,因为我可以通过删除对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部分,我不会得到错误。 但是,我想知道是否有人知道为什么删除需要的库的引用将会解决这个问题。 链接器如何知道在哪个库中查找? 另外 – 是否有一种方法来查询构build的可执行文件,并说'你是哪个库解决引用'楼'? 显然,有一些事情我不明白,这让我感到困扰。

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

  1. 你的libgplot.a依赖于libm.so ,但链接行上的-lm-lgplot的顺序是错误的。 链接行上的库的顺序很重要 。 通常,系统库( -lpthread-lm-lrt-ldl )应该遵循链接线上的所有其他内容。

  2. 从链接中删除-lmlibm.so.6仍然会被链接行( libgdlibxml2libcurl )中稍后出现的其他库所牵引,因为该库依赖于libm.so.6 。 但是现在libm.so.6在链接上是正确的,所以一切正常。

如果我在链接命令的末尾加上-lm,把它列为最后一个库,我不会得到这个错误。

这证实了上面的解释。

我已经解决了与export LDFLAGS="$LDFLAGS -lm"相同的问题export LDFLAGS="$LDFLAGS -lm"

也许,你的库searchpath(/ usr / local / lib /或/ usr / lib /,…)不包含64位libm,因此如果用l标志指定,gcc将无法find它。 如果你只指定目录,它看起来像可以find正确的目录。 所以你可以尝试:

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

并使用-lm

很难说。 因为在命令行中有自定义库目录,所以可以设想-lm链接不兼容的替代版本。 如果没有-lm ,链接器可能会插入另一个版本,因为链接库中的一个库需要它。

为了确保strace两个调用,并查看libm.so来自哪里。

顺便说一句, -Wl开关似乎什么都不做, -L/usr/lib/x86_64-linux-gnu被提及两次。

只是要添加到答案列表, http://fedoraproject.org/wiki/UnderstandingDSOLinkChange这是信息。 这与上面提到的问题没有关系,但是解释与错误信息/usr/bin/ld: note: 'some_reference' is defined in DSO some.so so try adding it to the linker command line

一个解释可能是:

这可能是一个在libm之外定义的弱链接函数foo ,它由在libm中定义的foo的强连接版本取代,而且这个强链接版本调用了未定义的函数。

这将解释如何添加库可能导致未定义的函数错误。

我遇到了类似的问题, 我记得在过去的海湾合作委员会,图书馆的顺序并不重要(至less在我没有使用过的情况下)。 在这个问题上,有人注意到,行为似乎在4.4和4.5之间发生了变化。

在我的情况下,我通过执行链接来摆脱错误消息:

  g++ -Wl,--copy-dt-needed-entries [options] [libraries] [object files] -o executable-file 

用这个:

 administrator@administrator-Veriton-M200-H81:~/ishan$ gcc polyscanline1.cpp -lglut -lGLU -lGL -lm