GCC的libm不工作 [英] GCC libm not working

查看:300
本文介绍了GCC的libm不工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个调用正弦,余弦和ACOS一个C程序。当我编译我收到以下错误:

I have a c program that calls sin, cos, and acos. When I compile I get the following errors:

/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

我知道这是常见的,当你不使用gcc的-lm标志。我使用该标志。我打电话GCC是这样的:

I know this is common when you don't use the -lm gcc flag. I AM using this flag. I'm calling GCC like this:

gcc -o zipcode-server -lm main.c

当我编译在我的一台计算机能正常工作。我能想到的唯一的区别是,这是不工作的64位x86和它的工作对电脑的i686。两者都是Ubuntu Linux系统。该文件libm.a是在计算机上present它不工作,我没有得到任何错误说,它不能被发现。可能是什么原因?

When I compile on one of my computers this works fine. The only difference that I can think of is that this isn't working on x86_64 and the computer it does work on is i686. Both are Ubuntu. The file libm.a is present on the computer it isn't working on and I don't get any errors saying it can't be found. What could be causing this?

推荐答案

您应该把 -lm 的main.c

在一般情况下,如果有多个库,他们应该写在他们的使用顺序。例如,如果库 A 使用库 B ,你应该有 -La -lb

In general, if you have multiple libraries, they should be written in order of their usage. For example, if library A uses library B, you should have -lA -lB.

在你的情况下,对象文件是的main.c 的编译结果使用库 M 和因此, -lm 要来后。

In your case, the object file that is the result of compilation of main.c uses library m and therefore -lm should come after it.

有关的好奇,这主要是出于效率的考虑。有了这个计划,链接器可以用在参数列表中看到每一个新的图书馆解决目前未知符号,并在途中该库拿起新的未知的符号。这意味着,连接体可以访问库逐个,因此匹配未知符号针对少数由每个库提供的符号

For the curious, this is mostly for efficiency reasons. With this scheme, the linker can resolve currently unknown symbols with every new library seen in the argument list, and picking up new unknown symbols from that library on the way. This means that the linker can visit the libraries one by one, and therefore match the unknown symbols against a small number of symbols provided by each library.

在对比度,链接器可以同时加载在所有图书馆的符号,然后开始匹配未知符号。然而,在这种情况下,链接程序需要处理符号的更大数目,同时增加内存占用和接头的执行时间。

On the contrast, the linker could load in symbols from all libraries at once, and then start matching unknown symbols. In that case however, the linker needs to deal with a much greater number of symbols, increasing both the memory footprint and the execution time of the linker.

由于库总是可以声明为连接器在其依赖的正确顺序 1 ,没有理由链接器选择低效的方式。

Since the libraries could always be declared to the linker in the proper order of their dependencies1, there is no reason for the linker to choose the inefficient way.

1 <子>库通常具有一个单向的关系,在这个意义上,一个使用另一个。库之间的循环依赖是罕见的,如果在所有现有的,但它仍然可以通过重复某些库,以复验与此模型中使用。

这篇关于GCC的libm不工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆