一尘不染

GCC libm无法正常工作

linux

我有一个调用sin,cos和acos的ac程序。编译时出现以下错误:

/tmp/ccDfW98S.o: In function `zip_search':
main.c:(.text+0xf30): undefined reference to `sin'
main.c:(.text+0xf45): undefined reference to `sin'
main.c:(.text+0xf66): undefined reference to `cos'
main.c:(.text+0xf7b): undefined reference to `cos'
main.c:(.text+0xf9c): undefined reference to `cos'
main.c:(.text+0xfc6): undefined reference to `acos'
collect2: ld returned 1 exit status

我知道当您不使用-lm gcc标志时这很常见。我正在使用此标志。我这样称呼GCC:

gcc -o zipcode-server -lm main.c

当我在其中一台计算机上进行编译时,这可以正常工作。我能想到的唯一区别是,它不能在x86_64上运行,而可以在其上运行的计算机是i686。两者都是Ubuntu。文件libm.a存在于无法使用的计算机上,并且我没有收到任何错误消息称无法找到它。是什么原因造成的?


阅读 451

收藏
2020-06-03

共1个答案

一尘不染

你应该把-lmmain.c

通常,如果您有多个库,则应按使用顺序编写它们。例如,如果library A使用library B,则应具有-lA -lB

在您的情况下,目标文件是main.c使用库的编译结果,m因此-lm应该放在它之后。


出于好奇,这主要是出于效率方面的考虑。使用此方案,链接器可以使用参数列表中显示的每个新库来解析当前未知的符号,并在此途中从该库中获取新的未知符号。这意味着链接器可以一个一个地访问库,因此将未知符号与每个库提供的少量符号进行匹配。

相反,链接器可以一次从所有库中加载符号,然后开始匹配未知符号。但是,在那种情况下,链接器需要处理大量符号,从而增加了内存占用量和链接器的执行时间。

由于可以始终以其依赖项1的正确顺序向链接器声明库,因此链接器没有理由选择低效的方式。

1
图书馆通常具有单向关系,即一个图书馆使用另一种图书馆。库之间的循环依赖关系很少存在(即使存在),但是仍然可以通过重复某些要重新检查的库与该模型一起使用。

2020-06-03