非常奇怪的链接器行为 [英] Very strange linker behavior

问题描述

  gcc这很奇怪，因为我可以通过移除对libm的引用来消除下面的错误。 -o示例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）：未定义引用符号'floor @@ GLIBC_2.2.5'
 / usr / bin / ld：note：'floor @@ GLIBC_2.2.5'在DSO /usr/lib/x86_64-linux-gnu/libm.so中定义，因此请尝试将其添加到链接器命令行
 / usr / lib / x86_64-linux-gnu / libm。因此：无法读取符号：操作无效
 collect2：ld返回1退出状态
  

，如果我删除命令的 -lm 部分，我不会收到错误信息。然而，我想知道是否有人知道为什么删除需要的库的引用可以解决这个问题。链接器如何知道要查找哪个库？另外 - 有没有办法查询一个内置的可执行文件，并说'你解决了'楼'的引用哪个库？很明显，有一些事情我不明白，而且让我困扰......

解决方案

解释什么是发生的事情很简单：

1. 您的 libgplot.a code> libm.so ，但是 -lm 和 -lgplot >在连接线上是错误的。
   链接行上的库的顺序 一>。通常，系统库（ -lpthread ， -lm ， -lrt ， -ldl ）应该跟随链接线上的其他所有内容。




2. 当你从链接中删除 -lm 时， libm.so.6 仍然被拉入由链接行后面的一些其他库链接（ libgd ， libxml2 或 libcurl ），因为该库依赖于 libm.so.6 。但是现在 libm.so.6 在链接行中是正确的，所以一切正常。

如果我在链接命令末尾加上-lm，将其列为最后一个库，我不会收到错误信息。

这证实了上面的解释。

This is strange because I was able to get the error below to go away by removing the reference to 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

So, if I remove the -lm part of the command, I do not get the error. However, I wonder if anyone knows as to why removing a reference to a library that is needed would fix this. How does the linker know which library to look in? Also - is there a way to query a built executable and say 'which library did you resolve the reference to 'floor'? obviously, there is something going on that I don't understand, and that bothers me...

解决方案

The explanation to what's happening is very simple:

1. Your libgplot.a depends on libm.so, yet the order of -lm and -lgplot on the link line is wrong. The order of libraries on the link line does matter. In general, system libraries (-lpthread, -lm, -lrt, -ldl) should follow everything else on the link line.

2. When you remove -lm from the link line, libm.so.6 is still pulled into the link by some other library that appears later on the link line (libgd, libxml2 or libcurl) because that library depends on libm.so.6. But now libm.so.6 is in correct place on the link line, and so everything works.

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

That confirms above explanation.

这篇关于非常奇怪的链接器行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！