zhanzc

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

转自:http://www.lingcc.com/2012/05/31/12093/
“undefined reference to XXX”是一类挺常见的链接错误,原因通常是链接时找不到声明成extern类型的函数的定义点。不过这次遇到的undefined reference中的XXX函数明明在一个库中定义,而且该库明明已经在命令行用-l指定了,ld –verbose也显示能找到该库文件。

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 参考

    最近在Linux下编程发现一个诡异的现象,就是在链接一个静态库的时候总是报错,类似下面这样的错误:

  1. (.text+0x13): undefined reference to `func' 

    关于undefined reference这样的问题,大家其实经常会遇到,在此,我以详细地示例给出常见错误的各种原因以及解决方法,希望对初学者有所帮助。

1.  链接时缺失了相关目标文件(.o)

    测试代码如下:

 

    然后编译。

  1. gcc -c test.c  
  2. gcc –c main.c 

    得到两个 .o 文件,一个是 main.o,一个是 test.o ,然后我们链接 .o 得到可执行程序:

gcc -o main main.o 

    这时,你会发现,报错了:

  1. main.o: In function `main':  
  2. main.c:(.text+0x7): undefined reference to `test'  
  3. collect2: ld returned 1 exit status 

    这就是最典型的undefined reference错误,因为在链接时发现找不到某个函数的实现文件,本例中test.o文件中包含了test()函数的实现,所以如果按下面这种方式链接就没事了。

  1. gcc -o main main.o test.o 

   【扩展】:其实上面为了让大家更加清楚底层原因,我把编译链接分开了,下面这样编译也会报undefined reference错,其实底层原因与上面是一样的。

  1. gcc -o main main.c //缺少test()的实现文件 

需要改成如下形式才能成功,将test()函数的实现文件一起编译。

  1. gcc -o main main.c test.c //ok,没问题了 

2.    链接时缺少相关的库文件(.a/.so)

    在此,只举个静态库的例子,假设源码如下。

    先把test.c编译成静态库(.a)文件

  1. gcc -c test.c  
  2. ar -rc test.a test.o 

    至此,我们得到了test.a文件。我们开始编译main.c

  1. gcc -c main.c 

    这时,则生成了main.o文件,然后我们再通过如下命令进行链接希望得到可执行程序。

  1. gcc -o main main.o 

    你会发现,编译器报错了:

  1. /tmp/ccCPA13l.o: In function `main':  
  2. main.c:(.text+0x7): undefined reference to `test'  
  3. collect2: ld returned 1 exit status 

    其根本原因也是找不到test()函数的实现文件,由于该test()函数的实现在test.a这个静态库中的,故在链接的时候需要在其后加入test.a这个库,链接命令修改为如下形式即可。

  1. gcc -o main main.o ./test.a  //注:./ 是给出了test.a的路径 

     【扩展】:同样,为了把问题说清楚,上面我们把代码的编译链接分开了,如果希望一次性生成可执行程序,则可以对main.c和test.a执行如下命令。

  1. 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文件。

  1. gcc -c func.c  
  2. gcc -c test.c  
  3. gcc -c main.c 

    然后,将test.c和func.c各自打包成为静态库文件。

  1. ar –rc func.a func.o  
  2. ar –rc test.a test.o 

    这时,我们准备将main.o链接为可执行程序,由于我们的main.c中包含了对test()的调用,因此,应该在链接时将test.a作为我们的库文件,链接命令如下。

  1. gcc -o main main.o test.a 

    这时,编译器仍然会报错,如下:

  1. test.a(test.o): In function `test':  
  2. test.c:(.text+0x13): undefined reference to `func'  
  3. collect2: ld returned 1 exit status 

    就是说,链接的时候,发现我们的test.a调用了func()函数,找不到对应的实现。由此我们发现,原来我们还需要将test.a所引用到的库文件也加进来才能成功链接,因此命令如下。

  1. gcc -o main main.o test.a func.a 

    ok,这样就可以成功得到最终的程序了。同样,如果我们的库或者程序中引用了第三方库(如pthread.a)则同样在链接的时候需要给出第三方库的路径和库文件,否则就会得到undefined reference的错误。

4 多个库文件链接顺序问题

    这种问题也非常的隐蔽,不仔细研究你可能会感到非常地莫名其妙。我们依然回到第3小节所讨论的问题中,在最后,如果我们把链接的库的顺序换一下,看看会发生什么结果?

  1. gcc -o main main.o func.a test.a 

    我们会得到如下报错.

  1. test.a(test.o): In function `test':  
  2. test.c:(.text+0x13): undefined reference to `func'  
  3. collect2: ld returned 1 exit status 

    因此,我们需要注意,在链接命令中给出所依赖的库时,需要注意库之间的依赖顺序,依赖其他库的库一定要放到被依赖库的前面,这样才能真正避免undefined reference的错误,完成编译链接。

5. 在c++代码中链接c语言的库

    如果你的库文件由c代码生成的,则在c++代码中链接库中的函数时,也会碰到undefined reference的问题。下面举例说明。

    首先,编写c语言版库文件: 

    

    编译,打包为静态库:test.a

  1. gcc -c test.c  
  2. ar -rc test.a test.o 

    至此,我们得到了test.a文件。下面我们开始编写c++文件main.cpp

    

    然后编译main.cpp生成可执行程序:

  1. g++ -o main main.cpp test.a 

    会发现报错:

  1. /tmp/ccJjiCoS.o: In function `main': 
  2. main.cpp:(.text+0x7): undefined reference to `test()' 
  3. collect2: ld returned 1 exit status 

    原因就是main.cpp为c++代码,调用了c语言库的函数,因此链接的时候找不到,解决方法:即在main.cpp中,把与c语言库test.a相关的头文件包含添加一个extern "C"的声明即可。例如,修改后的main.cpp如下:

    

  1. g++ -o main main.cpp test.a 

    再编译会发现,问题已经成功解决。

6.  总 结

    当然,上面几种是我目前发现的比较常见的undefined reference错误的原因和解决方法,可能也有其他各种原因,欢迎大家来信lujun.hust@gmail.com交流,对本文档进行补充,方面新手们解决学习过程中遇到的各种问题。

 

 

posted on 2013-09-27 21:31  zhanzc  阅读(48818)  评论(0编辑  收藏  举报