gcc参数顺序

gcc参数顺序
Ordering of gcc parameters matters

2013年最后一个月最后一个星期谈一个奇怪的bug，我在尝试pinfo的时候，configure脚本会提示ncurses有问题：

checking location of curses.h file... /usr/include/ncurses.h
checking if curses is usable... no
configure: error: Curses not found. You need curses to compile pinfo

打开config.log文件，发现这个提示：

configure:12563: checking if curses is usable
configure:12587: gcc -o conftest -g -O2 -I/usr/include    -L/usr/lib -lncurses conftest.c  >&5
/tmp/ccBLkSqd.o: In function `main':
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:38: undefined reference to `initscr'
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:39: undefined reference to `printw'
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:40: undefined reference to `stdscr'
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:40: undefined reference to `wrefresh'
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:41: undefined reference to `stdscr'
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:41: undefined reference to `wgetch'
/net/fantasia/home/zhanxw/software/pinfo-0.6.10/conftest.c:42: undefined reference to `endwin'
collect2: ld returned 1 exit status

从这个命令行来看，curses库的头文件目录和库文件目录都对，但编译的时候（链接/tmp/ccBLkSqd.o）却找不到几个函数的定义（比如：initscr，printw等等）。为了重现这个看起来不该出现的问题，我把conftest.c创建好，然后用相同的gcc命令行编译代码，的确是可以重现错误。

更令我不解的是如果把conftest.c放到命令行的末尾，这个编译就能通过了：

# This does not work
gcc -o conftest -g -O2 -I/usr/include    -L/usr/lib -lncurses conftest.c 
# This works
gcc -o conftest conftest.c -g -O2 -I/usr/include    -L/usr/lib -lncurses  

为什么把conftest.c移到“-L/usr/lib -lncurses”前面就能解决问题？
看到StackOverFlow上的一个帖子：

这个帖子讲到gcc编译和链接一个源程序时，会保留参数的顺序，也就是说在链接时，把conftest.c放到前面和后面，效果不同。具体来讲：

conftest.c 放到后面

gcc -o conftest -g -O2 -I/usr/include    -L/usr/lib -lncurses conftest.c 
<=> 等价于
gcc -o conftest -g -O2 -L/usr/lib -lncurses tmporary_object_file.o

conftest.c 放到前面

gcc -o conftest -g -O2 -I/usr/include conftest.c -L/usr/lib -lncurses 
<=> 等价于
gcc -o conftest -g -O2 tmporary_object_file.o -L/usr/lib -lncurses 

也就是说，gcc在链接目标文件时，会依照命令行的顺序，对于每个在前面目标文件中没有定义的函数，都试着在其后面的目标文件找找，如果最后一个目标文件也找不到，就报错。因此在我们的例子里，tmporary_object_file.o一定要放到-L/usr/lib -lncurses前面才能正确编译。

回到本文最开始，我们如何让configure把conftest.c放到“-L”前面？答案不是改动configure，而是使用LIBS环境变量：

LIBS="-L/usr/lib -lncurses" ./configure

与LIBS不同，LDFLAGS会放到conftest.c前面，这样configure还是没法正确的使用configure。

在本文最后，回想我们本来的问题，就是说gcc的参数有一定的顺序要求。也许gcc的手册里写了顺序的要求，但是很少有人能够看完gcc的手册。如果见到类似问题，应该怎么办呢？我觉得可以有两个思路，第一个就是想想写gcc软件的人是怎么想的。比如现在gcc的选择就是一个很方便的方法，如果当前没某个函数没有定义，就在他后面制定的目标文件里找找。如果这个要求反过来，或者任何顺序都支持，那么链接的函数就会复杂（因为链接程序需要存储所有定义过的函数，参见链接）；第二个就是想想传统的（或者标准的）写法是什么，把已知的经验和这个错误联系起来。比如configure的错误看起来很奇怪，但是先按照传统的写法先编译后链接，找到一个能凑合工作的方案（把conftest.c放到前面），再逐步改变到出错时的命令行，这个逐步的过程可以帮助查错也能巩固一下已有的知识。