undefined symbol: __gmpz_limbs_write 问题分析和解决

一、问题

最近用git克隆项目时出现了如题的报错，一顿操作下来，发现这库还是个系统库，没法更新也不能卸载重装，对比了另一台ubuntu文件的md5发现文件也没有损坏。。。

二、分析

• 1、使用 ldd -r 指令，查看该文件依赖了哪些动态库，并且存在哪些 undefined symbol 符号

ldd -r /lib/x86_64-linux-gnu/libgnutls.so.30

可以看到未定义的符号挺多，而且报错符号确实来自该动态库

• 2、使用指令 readelf -s 确认 libgnutls.so.30 里面定义了该符号(函数)

readelf -s /lib/x86_64-linux-gnu/libgnutls.so.30 | grep __gmpz_limbs_write

可以看到动态库里面确实定义了这个全局符号，那问题是什么呢？难道是函数调用不了？

检查前面的过程，可以看到有个比较"离谱"的路径。这里的意思是说 libgnutls.so.30 依赖了另一个动态库 libgmp.so.10，而该动态库来自路径 /disk/sdk/compiler/…，想都不用想，这肯定是不对的呀！

在相同的系统路径下，我们可以找到这个动态库本体正确的位置。那究竟是什么时候链接出错了呢？

• 3、检查 LD_LIBRARY_PATH 环境变量。(容易混淆的还有另一个环境变量 PATH，可以简单理解为前者是用来为执行程序找动态库的，而后者是用来找执行程序的，两个打配合，我们就可以在任意目录下运行一个其它地方的执行程序了)

echo $LD_LIBRARY_PATH

可以看到路径 /disk/sdk/compiler/… 确认来自该环境变量

通过这么一查，我就想起来了，是我之前配置过 ~/.bashrc，在里面添加过环境变量。注释掉下面两行，重启电脑，问题解决！

三、总结

• 1、使用指令 ldd -r 检查来源动态库，确认符号所在文件、确认有无异常的链接库来源；

• 2、确认动态库内是否定义了某个函数符号，可以用指令 readelf -s (其实也可以用 strings 指令)；

• 3、出现异常的链接库来源，多数是由环境变量 LD_LIBRARY_PATH 引入的，检查在哪里配置过该环境变量，修复后重启电脑即可。