【C++】undefined reference to找不到符号问题汇总及解决方法
目录
undefined reference to找不到符号问题汇总及解决方法
undefined reference to找不到符号问题汇总及解决方法
2022-06-08 14:52:42
大部分摘抄自:《undefined reference to" 问题解决方法》
CSDN--https://blog.csdn.net/aiwoziji13/article/details/7330333
SegmentFault--https://segmentfault.com/a/1190000006049907?utm_source=tuicool&utm_medium=referral
关于undefined reference问题常见错误的原因以及解决方法
1. 链接时缺失了相关目标文件(.o)
测试代码如下:
// test.h
#ifndef __TEST_H__
#define __TEST_H__void test();
#endif
// test.c
#include <string.h>
#include <stdio.h>void test()
{
printf("just test it\n");
}// main.c
#include "test.h"
int main(int argc, char **argv)
{
test();return 0;
}
然后编译。
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. 链接的库文件中又使用了另一个库文件
这种问题比较隐蔽,举例说明如下,首先,还是看看测试代码。
// func.h
#ifndef __FUNC_H__
#define __FUNC_H__void func();
#endif
// func.c
#include <stdio.h>
void func()
{
printf("call it\n");
}// test.h
#ifndef __TEST_H__
#define __TEST_H__void test();
#endif
// test.c
#include <string.h>
#include <stdio.h>#include "func.h"
void test()
{
printf("just test it\n");func();
}// main.c
#include "test.h"
int main(int argc, char **argv)
{
test();return 0;
}
从上图可以看出,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.定义与实现不一致
编写测试代码如下:
// test.h #ifndef __TEST_H__ #define __TEST_H__ void test(unsigned int c); #endif // test.c #include <string.h> #include <stdio.h> void test(int c) { printf("just test it\n"); } // main.c #include "test.h" int main(int argc, char **argv) { test(5); return 0; }
先将test.c
编译成库文件。
$ gcc -c test.c $ ar -rc test.a test.o
将main.c
编译成可执行文件。
$ gcc -o main main.c test.a ld: warning: ignoring file test.a, file was built for archive which is not the architecture being linked (x86_64): test.a Undefined symbols for architecture x86_64: "_test", referenced from: _main in main-f27cf1.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
链接出错了,原因很简单,test()
这个函数的声明和定义不一致导致,将两者更改成一样即可通过编译。
6.在c++代码中链接c语言的库
如果你的库文件由c代码生成的,则在c++代码中链接库中的函数时,也会碰到undefined reference的问题。下面举例说明。
代码同示例一的代码一样,只是把main.c
更改成了main.cpp
。编译test.c
,并打包为静态库。
$ gcc -c test.c $ ar -rc test.a test.o
编译可执行文件,用如下命令:
$ g++ -o main main.cpp test.a Undefined symbols for architecture x86_64: "test()", referenced from: _main in main-7d7fde.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
原因就是main.cpp
为c++
代码,调用了c
语言库的函数,因此链接的时候找不到,解决方法是在相关文件添加一个extern "C"
的声明即可,例如修改test.h
文件。
// test.h #ifndef __TEST_H__ #define __TEST_H__ #ifdef __cplusplus extern "C" { #endif void test(); #ifdef __cplusplus } #endif #endif
首先,编写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
再编译会发现,问题已经成功解决。
7.C++中类中静态变量没有在类外初始化
C++类里面的静态成员变量 只是声明了,还没有定义,需要还类外面定义。
//test.cpp
#include <stdio.h>
class A {
public:
static int a; //声明但未定义
};
int main() {
printf("%d", A::a);
return 0;
}
编译以上代码会出现“对‘A::a’未定义的引用”错误。这是因为静态成员变量a未定义,也就是还没有分配内存,显然是不可以访问的。
静态成员变量在类中仅仅是声明,没有定义,所以要在类的外面定义,实际上是给静态成员变量分配内存。
//test.cpp
#include <stdio.h>
class A {
public:
static int a; //声明但未定义
};int A::a = 3; //定义了静态成员变量,同时初始化。也可以写"int A:a;",即不给初值,同样可
以通过编译
int main() {
printf("%d", A::a);
return 0;
}
8.inline函数
1)如果将函数的实现放在cpp文件中,并且标记为inline, 那么该函数对其他编译单元不可见(类似static的效果),也就是其他cpp文件不能链接该函数库,这就是标题中出现的 … undefined reference to … :https://blog.csdn.net/GW569453350game/article/details/77934568
2) 开了优化,inline的函数被优化
nm命令还是比较简单而且强大的。它用来列出一个目标文件中的各种符号。符号的种类很多,以下是一些常见的符号类型
nm输出字符 含义
R Read only symbol. 比如在代码中有一个const MAXDATA = 3095; 则MAXDATA就是一个Read only symbol
N 这是一个调试符号
D 这是一个已经初始化的变量的符号。比如代码中int i = 1和char *str = "Hello"则i和str都是这种类型的符号
T Text段的符号。子程序都是这种符号,比如文件中实现了一个函数function,则function就是这种符号
U 未定义的符号。如果文件中引用了不存在的函数,则这些未定义的函数符号就是这种类型
S 未初始化的符号,比如全局变量int s;则s的符号就是此类型
nm命令的详细用法以及例子见正文。
至此,我们可以推断:动态库中有未定义的符号,说明该动态库的编译有问题,即是如下原因之一:
(1)一是使用者自己定义的函数或者全局变量所在源代码文件,没有被编译、连接。
(2)一是使用者自己定义的函数或者全局变量没有定义。
这种问题的解决,首先就要检查动态库的makefile写的是否有问题。
原文链接:https://blog.csdn.net/xiaolifeidaofirst/article/details/123073959
9.GCC的visibility属性隐藏
GCC的visibility属性用来控制.so文件的符号表,也就是控制外部能不能找到符号调用,比如函数、变量、模板、类等。符号表分静态的 .symtab 和动态的 .dynsym,一个对应链接视图另一个对应执行视图。设置为 hidden 符号将不导出,即不出现在 .dynsym 当中,不能为模块外所用。
默认是可见,这也就是“default”的含义。
在编译文件中:
1. 当-fvisibility=hidden时
动态库中的函数默认是隐藏的,除非代码中显示声明为__attribute__((visibility("default"))).
2. 当-fvisibility=default时
动态库中的函数默认是可见的,除非代码中显示声明为__attribute__((visibility("hidden"))).
原文链接:https://blog.csdn.net/weixin_36389889/article/details/126366321
undefined symbol问题的查找、定位与解决方法
( 2021-04-15 22:51:34)
原文链接:https://blog.csdn.net/buknow/article/details/96130049
今天被客户测出来一个问题:程序执行中报错,报错内容如下
XXXX:symbol lookup error:/home/....../libpdfium.so:undefined symbol:CRYPT_MD5Generate
报错分析:
这个问题表明是符号未定义的问题,而且直接定位于产品链接的第三方动态库libpdfium.so中,于是从libpdfium.so中着手。
因为有这个第三方库的源码,给错误的查找提供了可能。
错误定位:
但是这个符号未定义的错误很头疼,因为在我原来的想法中,符号位定义不应该是直接是在编译的时候就应该报错的吗? 所以为了确认,我重新编译了一遍第三方源码,编译时没有报错,生成了新的so,替换进去重新运行,结果也还是会包符号未定义的错误。在网上查找,知道了在链接时链接有误也会造成后期的符号未定义的错误(参考内容见最后)。这块可以通过ldd -r命令查看生成的so是否存在符号未定义的内容。
看这些未定义的符号,缺的实在太多了,按理说不应该的。在我的情况里,生成libpdfium.so动态库时会链接好几个静态库文件。根据网上查到的资料,确认一下链接的静态库顺序是否正确。直接在第三方源码中全局搜索报错的字符串“CRYPT_MD5Generate”,发现有两处cpp文件中存在,一处是声明定义的,另一处是调用的。
而这块可以看到fpdf_parse_encrypt是依赖于下边的fx_crypt文件的,再看静态库,fpdf_parse_encrypt被编译成fpdfapi.a,而fx_crypt被编译进pdrm.a静态库,所以应该是fpdfapi.a要依赖于pdrm.a静态库的。再检查Makefile中链接顺序,发现顺序是反的!!!罪魁祸首找到了!就是Makefile中链接的顺序错误导致最终so中符号未定义!
下面附上我这次查找过程中用到的几个很有用的命令,和参考的资料。
编译生成动态链接库后,调用时出现:
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws on git:lichunhong/dev x [18:54:05] C:127
$ rosrun path_plan PathPlanSimulation
/home/lichunhong/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/devel/lib/path_plan/PathPlanSimulation:
symbol lookup error: /home/lichunhong/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib/libpathplan.so:
undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E
即 symbol lookup error: libpathplan.so: undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E
出现这种问题时,往往是链接时出现了问题,下面分3步解决
(1)使用file 命令查看 so库的架构,看看是否与平台一致
可以看到,当前so库架构为x86-64,可以在GNU/Linux平台下使用。平台与架构一致
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/motion_planner/bin on git:dev x [18:47:54]
$ file libpathplan.so
libpathplan.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked,
BuildID[sha1]=32ae641e73c547376df20ca94746fbf5507de415, not stripped
接下来,需要定位一下 undefined symbol的具体信息
(2)通过 ldd -r xxx.so 命令查看so库链接状态和错误信息
ldd命令,可以查看对应的可执行文件或库文件依赖哪些库,但可执行文件或库文件要求与操作系统的编译器类型相同,即电脑是X86的GCC编译器,那么无法通过ldd命令查看ARM交叉编译器编译出来的可执行文件或库文件。
如果想在Ubuntu等Linux宿主机上查看ARM交叉编译好的可执行程序和库文件的相关依赖关系,可以通过以下命令:
readelf -d xxx.so | grep NEEDED
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib on git:lichunhong/dev x [18:57:19]
$ ldd -r libpathplan.so
linux-vdso.so.1 => (0x00007ffec1bd8000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f186cc0a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f186c901000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f186c6eb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f186c321000)
/lib64/ld-linux-x86-64.so.2 (0x00007f186d27a000)
undefined symbol: pthread_create (./libpathplan.so)
undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E (./libpathplan.so)
undefined symbol: _ZN2cv3maxERKNS_3MatES2_ (./libpathplan.so)
undefined symbol: _ZN12ninebot_algo10AprAlgoLog8WriteLogE10LEVEL_TYPEPKcS3_z (./libpathplan.so)
undefined symbol: _ZN2cv6dilateERKNS_11_InputArrayERKNS_12_OutputArrayES2_NS_6Point_IiEEiiRKNS_7Scalar_IdEE (./libpathplan.so)
undefined symbol: _ZN2cvgtERKNS_3MatEd (./libpathplan.so)
undefined symbol: _ZN2cv8fastFreeEPv (./libpathplan.so)
undefined symbol: _ZN2cv3Mat5setToERKNS_11_InputArrayES3_ (./libpathplan.so)
undefined symbol: _ZN12ninebot_algo10AprAlgoLog9instance_E (./libpathplan.so)
可以看到有好多 undefined symbol ,其中就有提到的 _ZN12ninebot_algo10AprAlgoLog9instance_E 错误
(3) 使用 c++filt symbol 定位错误在那个C++文件中
从上面的undefined symbol中,通过c++filt <symbol>,可以定位到大多是opencv的问题
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib on git:lichunhong/dev x [19:04:26] C:1
$ c++filt _ZN2cv7waitKeyEi
cv::waitKey(int)
# lichunhong @ lichunhong-ThinkPad-T470p in ~/Documents/src/effective_robotics_programming_with_ros-master/catkin_ws/src/pathPlan/lib on git:lichunhong/dev x [19:04:31]
$ c++filt _ZN2cv3maxERKNS_3MatES2_
cv::max(cv::Mat const&, cv::Mat const&)
原文链接:https://blog.csdn.net/buknow/article/details/96130049