undefined symbol问题的查找、定位与解决方法

今天被客户测出来一个问题:程序执行中报错,报错内容如下

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&)

 

`undefined symbol fnctl64` 这种错误信息通常出现在 C 或 C++ 编程语言中,特别是当你尝试链接一个程序或库时遇到的问题。它表明编译器或链接器试图引用一个不存在或不可见的函数(即 `fnctl64` 函数),但在实际的代码或库中并未找到对应的定义。 ### 错误分析 1. **函数或变量声明问题**:你可能在代码中使用了一个未被正确定义的全局函数或变量 `fnctl64`。确保你已在适当的位置声明并定义了这个函数或变量。例如,在 C++ 中,如果是模板函数,则需确保正确使用模板语法。 ```cpp template<typename T> T fnctl64(); ``` 2. **头文件包含问题**:确保在使用 `fnctl64` 的地方包含了相应的头文件,其中应定义了该函数。如果这是一个自定义的函数,那么需要包含包含其定义的 .h 文件;如果是系统提供的库函数,则应正确包含相应的系统头文件。 例如,对于 Linux 下的函数,通常涉及到系统调用或内核功能,可能需要包含 `<unistd.h>` 或其他更具体的头文件。 ```cpp #include <unistd.h> ``` 3. **动态链接问题**:如果你正在链接动态链接库,确保该库中确实包含了 `fnctl64` 函数的实现。检查库文件路径是否正确设置,以及库是否已经被正确构建且包含所需的符号。 4. **静态链接问题**:如果问题出在静态链接库中,确认所有必要的库都已经链接进来。在链接命令中,应该显式列出所有的静态库依赖。 ### 解决方案 1. **检查并添加缺失的头文件**:确认所有使用 `fnctl64` 的部分都包含了正确的头文件,然后重新编译。 2. **重新编译或构建依赖库**:如果 `fnctl64` 是来自第三方库,确保该库已正确构建且包含了 `.a` 或 `.lib` 格式的静态库文件。如果有源码可用,你可以尝试重新编译库。 3. **检查项目构建设置**:确认编译选项没有禁用某个库或功能。有时候,构建脚本可能因为某种原因忽略了关键部分。 4. **调试**:使用调试器逐行执行代码,观察在使用 `fnctl64` 前后的程序状态变化。这有助于定位问题所在,比如是否真的存在未声明的符号。 5. **查阅文档**:查找 `fnctl64` 的官方文档或社区资源,确保理解它的正确使用方法和限制。 ### 示例代码段 (仅作示例,实际情况取决于具体需求) ```cpp #include <unistd.h> // 此处假设 fnctl64 需要包含此头文件 void example_function() { int ret = fnctl64(FOO); // 使用 fnctl64 函数作为示例 if(ret == -1) { perror("Error in fnctl64"); } } ``` 请根据具体情况调整上述解答内容,确保解决你的实际问题
评论 21
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值