c - GCC libm 不工作

Question

我有调用 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 存在于它不工作的计算机上，我没有收到任何错误说它找不到。这可能是什么原因造成的？

Answer 1

你应该-lm把main.c

通常，如果您有多个库，则应按使用顺序编写它们。例如，如果 libraryA使用 library B，你应该有-lA -lB.

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

---

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

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

由于库总是可以按照它们的依赖关系的正确顺序声明给链接器¹，因此链接器没有理由选择低效的方式。

¹ _{图书馆通常具有单向关系，即一个使用另一个。库之间的循环依赖是很少见的，如果存在的话，但它仍然可以通过重复某些要重新检查的库来与此模型一起使用。}