转自：http://www.lingcc.com/2012/05/31/12093/
“undefined reference to XXX”是一类挺常见的链接错误，原因通常是链接时找不到声明成extern类型的函数的定义点。不过这次遇到的undefined reference中的XXX函数明明在一个库中定义，而且该库明明已经在命令行用-l指定了，ld –verbose也显示能找到该库文件。
Table of Contents
1 快速解决方案
如果你只想立即解决此类问题，那么：
- 方法0： 首先检查XXX函数或者符号是否的确包含在命令行用 -l 参数指定的所有库里。 你可以通过先简单的grep XXX 的试试。（grep到XXX，只能代表库文件中包含该字符串，不等同于有XXX符号的定义。objdump可查看是否真的定义了XXX）。如果找不到，需要先添加相应的链接库选项到命令行中。假如包含XXX的是libaaa.a, 则需要在命令行添加-laaa。另外ld –verbose看看是否库文件路径指定正确。如果此招无效，接着往下看。
- 方法1： 不妨在命令的结尾处再添加一次 -laaa 参数试试。
- 方法2： 将-laaa选项用 “-Wl,–start-group ” 和”-Wl, –end-group”括起来试试。(即 “-Wl,–start-group … -laaa … -Wl,–end-group”)
- 方法3： 将命令行所指定的所有库（尤其是非libgcc.a,libc.a之类的标准库）用 ar重新打包成一个新的 .a文件试试。
也许以上四个方法能帮你解决问题。如果想了解这背后的门道，请继续阅读。
2 从extern说起
我们都知道C语言遵循先声明、后使用的原则。但为了支持模块化编程（即将程序代码拆分存储到多个文件中），不同文件中定义的符号可能会相互引用。如A文件中定义了函数XXX，B文件中的代码可能会调用XXX。在编译器生成的可执行文件中，需要提供某种支持使得执行到调用XXX的动作时，能自动跳转到A文件中定义XXX的位置开始执行XXX函数本身。因此编译器需要知道在可执行文件中XXX的引用点。
理论上编译器可以将A和B中的代码先整合成一个文件，并让XXX定义在前调用在后来解决这一问题。但当代码量很大时，每次小修改都需要编译所有代码，耗时太久。于是为了更好的支持增量编译（即每次仅编译最新修改过的文件），就需要在编译阶段先在XXX的调用点留出一个空槽出来，然后再增加一个链接过程，在链接的时候找到XXX定义的位置，将这个值填入槽中。
另外语言层面也需要扩展，否则编译器还会在B文件中傻傻的找XXX的定义，找不到就会报错。所以extern关键字被引入，它告诉编译器，留个空槽就符号XXX就行了，不要傻找了,这个函数在其他文件中已经定义。不仅仅是函数，其实许多全局的符号都可以声明成extern，如全局变量。
3 链接时符号定位
链接时，ld会首先把所有object文件中的相同的段合并，并为他们分配额空间，这样每个段中各个符号的定义位置就确定了。接着，ld就会在所有符号的引用点处，将为符号留下来的”空槽“，填上定义符号的地址。
4 解决方案背后的门道
4.1 方法0
因为命令行确实没有指出符号所在的库文件，所以报错。找到相应库文件，先添加到命令行中吧。
4.2 方法1
方法1是最直接简单的方式，在命令行的结尾再给ld一次找该符号的机会。理论上，因为已经知道符号就在该库中定义，所以ld就能从新添加的这个选项中找到该标号。此法对于简单的小规模程序很合适。
不过对于Makefile管理的大项目就不行了。因为通常大项目会定义“LIBS”之类的变量。若LIBS变量插在链接命令行的中间位置，且 Makefile 中链接命令过多，在逐个命令最后添加新选项可是个易出错、难维护的体力活。
4.3 方法2
这是最文雅的方式。用“ –start-group“ 和”–end-group”扩起来的 .a文件会被反复解析，直到所有的符号都找到定义。因为这些选项都是给链接器ld用的,所以加上了”-Wl,”,代表紧接的选项传给链接器。默认情况下，ld会自动加上“–start-group -lgcc -lgcc_eh -lc –end-group”.意思是找不到的符号／函数名就在这几个库里面使劲搜，因为这几个库太底层了，符号间有依赖。
虽然这种方式能避免方法1中易出错、难维护的体力活。不过因为需要反复的解析其中的库文件，如果.a文件过多过大的时候，会增加链接时间。
4.4 方法3
这是最KISS的方法，简单高效。既然多个.a文件间存在循环引用依赖，ld解决不了循环依赖关系。那么我们可以参考从集群、网格计算到云计算的进化过程。把一坨.a揉成一个.a文件(ar命令可以实现此操作），交给ld。这样循环依赖问题就解决了。
这种方式避免了ld反复解析同一个.a文件，降低链接时间开销。不过该方法比较适合项目开发时使用，因为需要调整Makefile，而且将哪些.a揉成一个.a也是一个问题。比如我遇到的错就是因为pthread库函数出现undefined reference，标准库很多的时候也有点头大。
5 参考
- http://stackoverflow.com/questions/45135/linker-order-gcc/409470#409470
- http://linux.die.net/man/1/ld
- http://stackoverflow.com/questions/45135/linker-order-gcc
- http://stackoverflow.com/questions/6045809/problem-with-g-and-undefined-reference-to-gxx-personality-v0
- http://linux.die.net/man/1/ar
- 程序员的自我修养–链接、装载与库。 俞甲子、石凡、潘爱民著
最近在Linux下编程发现一个诡异的现象，就是在链接一个静态库的时候总是报错，类似下面这样的错误：
- (.text+0x13): undefined reference to `func'
关于undefined reference这样的问题，大家其实经常会遇到，在此，我以详细地示例给出常见错误的各种原因以及解决方法，希望对初学者有所帮助。
1. 链接时缺失了相关目标文件（.o）
测试代码如下：
然后编译。
- gcc -c test.c
- gcc –c main.c
得到两个 .o 文件，一个是 main.o，一个是 test.o ，然后我们链接 .o 得到可执行程序：
gcc -o main main.o这时，你会发现，报错了：
- main.o: In function `main':
- main.c:(.text+0x7): undefined reference to `test'
- collect2: ld returned 1 exit status
这就是最典型的undefined reference错误，因为在链接时发现找不到某个函数的实现文件，本例中test.o文件中包含了test()函数的实现，所以如果按下面这种方式链接就没事了。
- gcc -o main main.o test.o
【扩展】：其实上面为了让大家更加清楚底层原因，我把编译链接分开了，下面这样编译也会报undefined reference错，其实底层原因与上面是一样的。
- gcc -o main main.c //缺少test()的实现文件
需要改成如下形式才能成功，将test()函数的实现文件一起编译。
- gcc -o main main.c test.c //ok,没问题了
2. 链接时缺少相关的库文件（.a/.so）
在此，只举个静态库的例子，假设源码如下。
先把test.c编译成静态库(.a)文件
- gcc -c test.c
- ar -rc test.a test.o
至此，我们得到了test.a文件。我们开始编译main.c
- gcc -c main.c
这时，则生成了main.o文件，然后我们再通过如下命令进行链接希望得到可执行程序。
- gcc -o main main.o
你会发现，编译器报错了：
- /tmp/ccCPA13l.o: In function `main':
- main.c:(.text+0x7): undefined reference to `test'
- collect2: ld returned 1 exit status
其根本原因也是找不到test()函数的实现文件，由于该test()函数的实现在test.a这个静态库中的，故在链接的时候需要在其后加入test.a这个库，链接命令修改为如下形式即可。
- gcc -o main main.o ./test.a //注：./ 是给出了test.a的路径
【扩展】：同样，为了把问题说清楚，上面我们把代码的编译链接分开了，如果希望一次性生成可执行程序，则可以对main.c和test.a执行如下命令。
- gcc -o main main.c ./test.a //同样，如果不加test.a也会报错
3. 链接的库文件中又使用了另一个库文件
这种问题比较隐蔽，也是我最近遇到的与网上大家讨论的不同的问题，举例说明如下，首先，还是看看测试代码。
从上图可以看出，main.c调用了test.c的函数，test.c中又调用了fun.c的函数。
首先，我们先对fun.c，test.c，main.c进行编译，生成 .o文件。
- gcc -c func.c
- gcc -c test.c
- gcc -c main.c
然后，将test.c和func.c各自打包成为静态库文件。
- ar –rc func.a func.o
- ar –rc test.a test.o
这时，我们准备将main.o链接为可执行程序，由于我们的main.c中包含了对test()的调用，因此，应该在链接时将test.a作为我们的库文件，链接命令如下。
- gcc -o main main.o test.a
这时，编译器仍然会报错，如下：
- test.a(test.o): In function `test':
- test.c:(.text+0x13): undefined reference to `func'
- collect2: ld returned 1 exit status
就是说，链接的时候，发现我们的test.a调用了func()函数，找不到对应的实现。由此我们发现，原来我们还需要将test.a所引用到的库文件也加进来才能成功链接，因此命令如下。
- gcc -o main main.o test.a func.a
ok，这样就可以成功得到最终的程序了。同样，如果我们的库或者程序中引用了第三方库（如pthread.a）则同样在链接的时候需要给出第三方库的路径和库文件，否则就会得到undefined reference的错误。
4 多个库文件链接顺序问题
这种问题也非常的隐蔽，不仔细研究你可能会感到非常地莫名其妙。我们依然回到第3小节所讨论的问题中，在最后，如果我们把链接的库的顺序换一下，看看会发生什么结果？
- gcc -o main main.o func.a test.a
我们会得到如下报错.
- test.a(test.o): In function `test':
- test.c:(.text+0x13): undefined reference to `func'
- collect2: ld returned 1 exit status
因此，我们需要注意，在链接命令中给出所依赖的库时，需要注意库之间的依赖顺序，依赖其他库的库一定要放到被依赖库的前面，这样才能真正避免undefined reference的错误，完成编译链接。
5. 在c++代码中链接c语言的库
如果你的库文件由c代码生成的，则在c++代码中链接库中的函数时，也会碰到undefined reference的问题。下面举例说明。
首先，编写c语言版库文件：
编译，打包为静态库：test.a
- gcc -c test.c
- ar -rc test.a test.o
至此，我们得到了test.a文件。下面我们开始编写c++文件main.cpp
然后编译main.cpp生成可执行程序：
- g++ -o main main.cpp test.a
会发现报错：
- /tmp/ccJjiCoS.o: In function `main':
- main.cpp:(.text+0x7): undefined reference to `test()'
- collect2: ld returned 1 exit status
原因就是main.cpp为c++代码，调用了c语言库的函数，因此链接的时候找不到，解决方法：即在main.cpp中，把与c语言库test.a相关的头文件包含添加一个extern "C"的声明即可。例如，修改后的main.cpp如下：
- g++ -o main main.cpp test.a
再编译会发现，问题已经成功解决。
6. 总 结
当然，上面几种是我目前发现的比较常见的undefined reference错误的原因和解决方法，可能也有其他各种原因，欢迎大家来信lujun.hust@gmail.com交流，对本文档进行补充，方面新手们解决学习过程中遇到的各种问题。