最近在centos下编译一个程序时，出现了一个问题，大致如下：


编译 a.cpp b.cpp c.cpp，其中a.cpp中含有main函数，a.cpp调用b.cpp所定义类的方法，而b.cpp里调用 c.cpp中的类的方法。生成 a.o b.o c.o 文件，最后链接生成可执行程序 test ，成功。

编译命令大致是这样的： 

g++ -Wall -g -I../include -o test a.o b.o c.o

但是 把 b.o c.o 编译成 libb.a libc.a 后，再链接生成可执行程序 test 时失败，编译命令大致是这样的：

g++ -Wall -g -L../lib -lbc -o test a.o

错误提示是说有些函数的定义找不到，“undefined reference  .... ” 之类的。查看libb.a和libc.a文件，是有定义的，但是链接时却找不到。后来请问同事和查阅g++手册才知道，命令行中库出现顺序是跟链接过程是相关的。 A 依赖 B ，则 B 库在命令行中应该出现在 A 的右边。下面给出g++ man中关于 -l 的描述：

  • -llibrary

  • -l library

  • Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)

    It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. Ifbar.o refers to functions in z, those functions may not be loaded.

    The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.

    The directories searched include several standard system directories plus any that you specify with -L.

    Normally the files found this way are library files---archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with lib and .a and searches several directories.

而又在mac上试一下，发现mac上的g++没有这个问题，链接时命令行中的库出现的顺序与库之间的依赖关系无关。同事说这是LLVM的关系，但我具体也未清楚原因，也不去深究原因，知道有这样便可以了。下面给出mac本下g++的版本

Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1

Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)

Target: x86_64-apple-darwin13.3.0

Thread model: posix

在freebsd上的c++编译器也试了一下，发现和linux上的g++存在同样的问题。下面给出c++编译器的版本：

FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512

Target: i386-unknown-freebsd10.1

Thread model: posix

除了库的依赖关系之外，还存在着.o文件与库之间的依赖关系。.o 文件如果依赖于一个库，则库应该出现在.o文件的右边。无论是库依赖库，或是.o文件依赖库，在库接命令行中，被依赖的要出现在依赖者的右边。出现这样的问题的原因在跟编译链接过程有关，由于我对编译过程也并不是十分清楚，不能很好地表达，所以就不解释了。


总结了一下，在编写编译链接命令时，最好把包含库部分写到命令的最后，同时把基础的库放在右边，这样就可以尽量减少出错。