GCC libm无效

Ste*_*art 9 c 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
Run Code Online (Sandbox Code Playgroud)

我知道当你不使用-lm gcc标志时这很常见.我正在使用这个标志.我这样叫GCC:

gcc -o zipcode-server -lm main.c
Run Code Online (Sandbox Code Playgroud)

当我在我的一台计算机上编译时,这很好用.我能想到的唯一区别是,这不适用于x86_64,而它运行的计算机是i686.两者都是Ubuntu.文件libm.a出现在它没有工作的计算机上,我没有得到任何错误,说它找不到.可能是什么导致了这个?

Sha*_*baz 23

你应该把-lmmain.c

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

在你的情况下,对象文件,是编译的结果,main.c使用库m,因此-lm应该跟从它.


对于好奇,这主要是出于效率原因.使用此方案,链接器可以使用参数列表中看到的每个新库来解析当前未知的符号,并在途中从该库中拾取新的未知符号.这意味着链接器可以逐个访问库,因此将未知符号与每个库提供的少量符号相匹配.

相反,链接器可以立即加载来自所有库的符号,然后开始匹配未知符号.但是,在这种情况下,链接器需要处理更多数量的符号,从而增加了内存占用量和链接器的执行时间.

由于库总是可以按其依赖关系1的正确顺序向链接器声明,因此链接器没有理由选择低效的方式.

1 图书馆通常具有单向关系,在某种意义上说,一个人使用另一个.如果存在的话,库之间的循环依赖性是罕见的,但是通过重复某些要重新检查的库,它仍然可以与此模型一起使用.