目录
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
29万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
