【linux】程序找不到动态库.so的解决办法|查看.so动态库信息|.so动态库加载顺序

目录

找不到.so解决方法

方法一：添加环境变量

方法二：复制so文件到lib路径

方法三：（推荐）添加ldconfig寻找路径

方法四：在编译目标代码时指定该程序的动态库搜索路径

让程序在本目录找到库.so

其他命令

查看程序依赖的.so库

查看动态库连接过程

查看一个so链接库的版本

查看So 的版本、GCC版本、GLIB版本

nm 查看动态库和静态库中的符号

动态库查找顺序

动态库[链接时]路径和[运行时]路径

修改efl文件（程序、库文件）的库依赖路径

链接静态库/动态库

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

---

作者：bandaoyu,本文动态更新，源址：https://blog.csdn.net/bandaoyu/article/details/113181179

找不到.so解决方法

ldd   程序名   ，查看程序去哪里找库，找到没

原理：

搜索.so的优先级顺序
RPATH：                       写在elf文件中
LD_LIBRARY_PATH： 环境变量
RUNPATH：                 写在elf文件中
ldconfig的缓存： 配置/etc/ld.conf*可改变
默认的/lib, /usr/lib

RPATH与RUNPATH中间隔着LD_LIBRARY_PATH。为了让用户可以通过修改D_LIBRARY_PATH来指定.so文件，大多数编译器都将输出的RPATH留空，并用RUNPATH代替RPATH。

原文：https://www.it610.com/article/1295147005911310336.htm

方法一：添加环境变量

（如果设置编译的时候指定了RPATH，这个设置可能就无效）

添加环境变量三种方式

1. 添加当前用户当前终端的环境变量（临时）

export LD_LIBRARY_PATH=/home/czd/...  #.so file path

2. 添加当前用户的环境变量

修改~/.bashrc文件，在其末尾，添加环境变量

vim ~/.bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/czd/...  #.so file path

使其生效，

source ~/.bashrc

如不能生效，请重启

3. 添加所有用户的环境变量

修改profile文件，在其末尾添加环境变量

vim /etc/profile
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/czd/...  #.so file path

使其生效

source /etc/profile

如不能生效，请重启

方法二：复制so文件到lib路径

linux系统的so库一般存储与“/usr/lib/”路径中，可将动态库复制到该路径中。

sudo cp liblibtest.so /usr/lib/

即时生效

方法三：（推荐）添加ldconfig寻找路径

程序加载动态库的时候实际是先加载ld.so，然后通过ld.so去加载其他库，所以配置ld.so.conf

但是加载顺序优优先级低于RPATH和LD_LIBRARY_PATH，所以前两者设置了，该配置可能无效

步骤1. 编辑链接配置文件

vim /etc/ld.so.conf，确认内容是否为如下，不是则修改为如下：

include /etc/ld.so.conf.d/*.conf

步骤2. 进入/etc/ld.so.conf.d目录内，创建*.conf文件,文件名随意，扩展名必须为.conf

cd /etc/ld.so.conf/
vim libmy.conf 

步骤4. 在文件内部，添加so的路径，保存并退出

/home/czd/eclipse-workspacee/calllib/Debug

步骤5. 执行命令时期生效

sudo ldconfig

程序在运行时寻找so库就会到添加的目录中寻找。

gcc 运行指定动态库的三种方法：https://blog.csdn.net/qq_38350702/article/details/106128030

方法四：在编译目标代码时指定该程序的动态库搜索路径

（优先级最高）

解决办法有两种，第一程序链接时指定链接库的位置，就是使用-wl,-rpath=参数，就是链接库的路径。如：

gcc -o foo foo.c -L. -lfoo -Wl,-rpath=/usr/mylib

上面就是指定了链接的位置在/usr/mylib，执行./foo时，foo会去/usr/mylib找libfoo.so库。

不过一般情况我们使用如下格式

gcc -o foo foo.c -L$(prefix)/lib -lfoo -Wl,-rpath=$(prefix)/lib

让程序在本目录找到库.so

1、为了让Linux能在本目录下找到so文件，需要修改.bash_profile。

2、在.bash_profile的最后位置添加代码：export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

其他命令

查看程序依赖的.so库

查看可以执行程序需要哪些动态库,以及是否能找到

ldd  /usr/bin/mount

[root@rdma64 lcx]# ldd ./ceph_perf_msgr_server_normal
        linux-vdso.so.1 =>  (0x00007ffc24dec000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6f9a6ee000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f6f9a4ea000)
        libmymalloc.so => not found
        libjemalloc.so.1 => not found
        libsnappy.so.1 => /lib64/libsnappy.so.1 (0x00007f6f9a0e2000)
        libceph-common.so.0 => ./bak/libceph-common.so.0 (0x00007f6f912d5000)

查看可以执行程序需要哪些动态库，使用命令：
readelf   -d  [可执行程序]   

查看动态库连接过程

查keep

ldconfig -v | grep keep

ldconfig -p | grep keep

查看一个so链接库的版本

如果要准确的版本，看看这个库文件链接到那个具体文件：

/lib# file libhandle.so

libhandle.so: symbolic link to `libhandle.so.1'

lib# file libhandle.so.1

libhandle.so.1: symbolic link to `libhandle.so.1.0.3'

可以看到经过两次链接，最终文件名中1.0.3是版本号，其它方法只能得出主版本号

查看So 的版本、GCC版本、GLIB版本

strings libc.so | grep Version

1. 查看GLIB版本信息

strings xxx | grep GLIB

~$ strings libGL.so  | grep GLIB
GLIBC_2.2.5
GLIBC_2.3.2
GLIBC_2.3
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.14
GLIBC_2.17

2. 查看GCC版本信息

strings xxx | grep GCC

~$ strings libGL.so  | grep GCC
GCC_3.0
GCC: (Debian 6.4.0-22) 6.4.0 20180924

原文链接：https://blog.csdn.net/ternence_hsu/article/details/103045847

nm 查看动态库和静态库中的符号

nm [option(s)] [file(s)]

有用的options:

• -A 在每个符号信息的前面打印所在对象文件名称；
• -C 输出demangle过了的符号名称；
• -D 打印动态符号；
• -l 使用对象文件中的调试信息打印出所在源文件及行号；
• -n 按照地址/符号值来排序；
• -u 打印出那些未定义的符号；

常见的符号类型:

• A 该符号的值在今后的链接中将不再改变；
• B 该符号放在BSS段中，通常是那些未初始化的全局变量；
• D 该符号放在普通的数据段中，通常是那些已经初始化的全局变量；
• T 该符号放在代码段中，通常是那些全局非静态函数；
• U 该符号未定义过，需要自其他对象文件中链接进来；
• W 未明确指定的弱链接符号；同链接的其他对象文件中有它的定义就用上，否则就用一个系统特别指定的默认值。

注意几点：

• -C 总是适用于c++编译出来的对象文件。还记得c++中有重载么？为了区分重载函数，c++编译器会将函数返回值/参数等信息附加到函数名称中去形成一个mangle过的符号，那用这个选项列出符号的时候，做一个逆操作，输出那些原始的、我们可理解的符号名称。
• 使用 -l 时，必须保证你的对象文件中带有符号调式信息，这一般要求你在编译的时候指定一个 -g 选项，见 Linux:Gcc。
• 使用nm前，最好先用Linux:File查看对象文件所属处理器架构，然后再用相应交叉版本的nm工具。

举例

更详细的内容见man page。这里举例说明：

nm -u hello.o

显示hello.o 中的未定义符号，需要和其他对象文件进行链接.

nm -A /usr/lib/* 2>/dev/null | grep "T memset"

在 /usr/lib/ 目录下找出哪个库文件定义了memset函数. 

动态库查找顺序

综合以上结果可知，动态库的搜索路径搜索的先后顺序是：

1.编译目标代码时指定的动态库搜索路径； //-L、-rpath和-rpath-link

2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径；

3.配置文件/etc/ld.so.conf中指定的动态库搜索路径；

4.默认的动态库搜索路径/lib；

5.默认的动态库搜索路径/usr/lib。

在上述1、2、3指定动态库搜索路径时，都可指定多个动态库搜索路径，其搜索的先后顺序是按指定路径的先后顺序搜索的。

Linux动态库(.so)搜索路径：http://blog.csdn.net/21aspnet/article/details/6724457

动态库[链接时]路径和[运行时]路径

-L、-rpath和-rpath-link的区别;http://blog.csdn.net/q1302182594/article/details/42102961( -L、-rpath和-rpath-link的区别)

现代连接器在处理动态库时将链接时路径（Link-time path）和运行时路径（Run-time path）分开。用户可以

• 通过-L 指定编译连接时库的路径
• 通过-R（或-rpath）指定程序运行时库的路径，

大大提高了库应用的灵活性。

比如我们在编译环境 gcc -o target -L /work/lib/zlib/  -llibz-1.2.3 (work/lib/zlib下是编译环境的动态库目录)，将target编译好后我们只要把zlib下的库文件拷贝到运行环境的系统默认路径下即可。或者通过-rpath（或-R ）、LD_LIBRARY_PATH指定查找路径。

链接器ld的选项有 -L，-rpath 和 -rpath-link，大致是这个意思：

-L: “链接”的时候，去找的目录，也就是所有的 -lxxx 选项里的库，都会先从 -L 指定的目录去找，然后是默认的地方。-L只是指定了程序编译连接时库的路径，并不影响程序执行时库的路径。

-rpath和-rpath-link都可以在链接时指定库的路径；但是运行可执行文件时，-rpath-link指定的路径就不再有效(链接器没有将库的路径包含进可执行文件中)，

而-rpath指定的路径还有效(因为链接器已经将库的路径包含在可执行文件中了。)

修改efl文件（程序、库文件）的库依赖路径

工具：patchelf
（RHEL 已经自带了chrpath工具，直接使用即可. ( yum install chrpath)不过chrpath 有个缺陷，如果当前系统为x86_64，则修改i386 elf会报错，patchelf则无此问题!）

rpath全称是run-time search path。Linux下所有elf格式的文件都包含它，特别是可执行文件。它规定了可执行文件在寻找.so文件时的第一优先位置。用patchelf修改它的信息。rpath和patchelf:https://www.cnblogs.com/ar-cheng/p/13225342.html

查看demo依赖的库：

$ readelf -d demo
 

路径修改

更改程序或库运行时搜索依赖库的路径（多个路径用冒号隔开）

$ patchelf  --set-rpath   /opt/my-libs/lib:/other-libs   my-program

增加本目录路径是一个“.”而不是“./”

$patchelf  --set-rpath   /opt/my-libs/lib:/other-libs:.   my-program

去掉冗余的依赖库路径（Shrink the RPATH of executables and libraries:）

$ patchelf  --shrink-rpath  my-program

去掉冗余的依赖库路径，但保留/usr/lib:/foo/lib前缀的路径

$ patchelf  --shrink-rpath  --allowed-rpath-prefixes  /usr/lib:/foo/lib  my-program

依赖修改

删除依赖（删除my-program对libfoo.so.1的依赖）

$ patchelf  --remove-needed  libfoo.so.1 my-program 

增加依赖（给my-program增加对libfoo.so.1的依赖）
$ patchelf  --add-needed        libfoo.so.1 my-program  

更换依赖。原本是依赖 liboriginal.so.1，改为依赖 libreplacement.so.1

$ patchelf  --replace-needed  liboriginal.so.1  libreplacement.so.1  my-program 

更改动态库的短名(SONAME) :
$ patchelf  --set-soname  libnewname.so.3.4.5  path/to/libmylibrary.so.1.2.3 

关于SONAME,见：https://blog.csdn.net/bandaoyu/article/details/115307641

Change the dynamic loader ("ELF interpreter") of executables
$ patchelf  --set-interpreter /lib/my-ld-linux.so.2 my-program 

教程：patchelf工具:https://blog.csdn.net/juluwangriyue/article/details/108617283

官网使用说明：

README.md
PatchELF is a simple utility for modifying existing ELF executables and libraries. In particular, it can do the following:

Change the dynamic loader ("ELF interpreter") of executables:
$ patchelf --set-interpreter /lib/my-ld-linux.so.2 my-program

Change the RPATH of executables and libraries:
$ patchelf --set-rpath /opt/my-libs/lib:/other-libs my-program

Shrink the RPATH of executables and libraries:
$ patchelf --shrink-rpath my-program

This removes from the RPATH all directories that do not contain a library referenced by DT_NEEDED fields of the executable or library. For instance, if an executable references one library libfoo.so, has an RPATH /lib:/usr/lib:/foo/lib, and libfoo.so can only be found in /foo/lib, then the new RPATH will be /foo/lib.

In addition, the --allowed-rpath-prefixes option can be used for further rpath tuning. For instance, if an executable has an RPATH /tmp/build-foo/.libs:/foo/lib, it is probably desirable to keep the /foo/lib reference instead of the /tmp entry. To accomplish that, use:

$ patchelf --shrink-rpath --allowed-rpath-prefixes /usr/lib:/foo/lib my-program

Remove declared dependencies on dynamic libraries (DT_NEEDED entries):
$ patchelf --remove-needed libfoo.so.1 my-program

This option can be given multiple times.
Add a declared dependency on a dynamic library (DT_NEEDED):
$ patchelf --add-needed libfoo.so.1 my-program

This option can be give multiple times.
Replace a declared dependency on a dynamic library with another one (DT_NEEDED):

$ patchelf --replace-needed liboriginal.so.1 libreplacement.so.1 my-program

This option can be give multiple times.

Change SONAME of a dynamic library:
$ patchelf --set-soname libnewname.so.3.4.5 path/to/libmylibrary.so.1.2.3

链接静态库/动态库

链接静态库

链接静态库libadd_minus.a

方式一

gcc -o main2 main.o -L./ -ladd_minus

说明1:-L./表明库文件位置在当前文件夹

说明2: -ladd_minus 表示链接 libadd_minus.a 文件,使用“-l”参数时,前缀“lib”和后缀“.a”是需要省略的。

方式二、

-L/your/library/path  -l:libmylib.a

如果-l:filename格式指定一个文件名，连接程序直接去找这个文件名了，不会再像使用-lname时将name扩展成lib.a格式的文件名.

当然如果库的位置不在gcc默认搜索路径中，要用-L参数另外指定搜索库的路径

在gcc编译链接时强制使用lib.a

当一个库文件既有.a又有.so时，如果这么写，gcc会优先链接.so文件：

gcc -L/path/to/library/ -ljemalloc -o run

有一种写法可以强制链接.a库文件：

gcc -L/path/to/library/ -l:libjemalloc.a -o run

这种写法也能解决当依赖库不是以libxxx.a或者libxxx.so规范命名时，可以通过指定库文件全名来解决。

链接动态库

gcc -o main4 main.o -L./ -ladd_minus -lmulti_div

说明1:-L./表明库文件位置在当前文件夹

说明2: -ladd_minus 表示链接 libadd_minus.so 文件,使用“-l”参数时,前缀“lib”和后缀“.so”是需要省略的。

• 参考
  https://www.shiyanlou.com/courses/849/learning/

/lib64/libc.so.6: version `GLIBC_2.25' not found

glibc是什么

glibc是GNU发布的libc库，即c运行库

检查本机 glibc 版本

ldd --version

原因是：使用高级的命令安装了软件，但是本机还是使用的是低级的依赖库，因此会出现这种情况；使用 ldd --version 可以查看 glibc 的版本为 2.17 可知，确实还是老的依赖库。

解决：升级 centos6.8 升级 glibc 到 2.25 版本

下载 glibc-2.25.tar.gz  编译安装 https://mirrors.cloud.tencent.com/gnu/glibc/
链接：https://www.jianshu.com/p/5bb21028cde1

tar zxvf glibc-2.25.tar.gz
cd glibc-2.25
mkdir build
cd build
../configure --prefix=/opt/glibc-2.25
make -j4
sudo make install
export LD_LIBRARY_PATH=/opt/glibc-2.25/lib

原文链接：https://blog.csdn.net/weixin_44479465/article/details/112703715

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

（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 ，可以定位到大多是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

ldd 生成详细信息，包括符号版本控制数据 -v：ldd -v test

 ldd 产生未使用的直接依赖关系 -u：ldd -u test

 ldd 查看是否缺少依赖库 -d：ldd -d test

 ldd 查看是否缺少符号和对象 -r：ldd -r test