gcc / g ++参数顺序

Joh*_*Doe 3 parameters linker gcc

我刚刚在新的ubuntu 12.10服务器上编译了chironfs,并收到以下错误:

gcc  -Wall -W -Wmissing-prototypes -g -O2 -DFUSE_USE_VERSION=25 -D_FILE_OFFSET_BITS=64 -I/usr/local/include -g -O2 -lm -lfuse  -o chironfs chironfs.o chiron-conf.o chirondbg.o chironfn.o  
chironfs.o: In function `chiron_init':
/root/chironfs-1.1.1/src/chironfs.c:2000: undefined reference to `pthread_create'
chironfs.o: In function `get_rights_by_name':
/root/chironfs-1.1.1/src/chironfs.c:452: undefined reference to `fuse_get_context'
Run Code Online (Sandbox Code Playgroud)

pthread错误告诉我-lpthread丢失,但是保险丝错误有点奇怪,因为正在使用-lfuse

我在这里找到了建议将库放在目标文件之后的解决方案

所以我删除了-lfuse并在行的最后添加了-lfuse -lpthread

现在它可以编译而没有错误,看来这就是应该的样子:目标文件后的库

我的问题是:为什么参数顺序与gcc / ld有关?我tough gcc像其他所有应用程序一样解析参数,并且可以将必要的参数转发给ld或此类

一般而言:任何人都知道gcc参数排序的事实或提示,也许还有些关于为什么需要这种方式的背景信息?

谢谢

von*_*and 5

对象和库的顺序与链接器相关(在创建可执行文件时,编译器会隐式调用该对象)。当链接器从左到右扫描发现不知道的名称时,便从此开始寻找定义。如果定义通过,它就不会记住它供以后使用。

  • 所以换句话说:错误的例子有问题,链接器找到了fuse和pthreads,但在他找到它们时没有使用它们,所以他删除了libs。工作示例首先告诉链接器,例如 chironfs.o 需要 pthreads,因此链接器开始搜索它并稍后从 chironfs.o 点在参数列表中找到它 - 熔丝也是如此,对吧? (2认同)
  • @JohnDoe,正是。是的,链接器是愚蠢的。抱歉,现在让它变得聪明为时已晚(很大程度上取决于它当前的行为)。 (2认同)