分析核心转储时共享库的相对路径
当我进行核心分析时，是否可以指定共享库的相对路径（我想在编译时而不是调试时指定相对路径）
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007f4433ffef00 0x00007f443402cc08 Yes (*) /lib/libssl.so.0.9.8
0x00007f44334d6a00 0x00007f44335e9920 Yes /lib/libc.so.6
0x00007f443423eaf0 0x00007f4434257994 Yes /lib64/ld-linux-x86-64.so.2
No ./lib/myplugin.so
No /opt/lib/mylibc.so
0x00007f443237a190 0x00007f443237d7f8 Yes /lib/librt.so.1
0x00007f44320f8ef0 0x00007f44321392d8 Yes /lib/libm.so.6
0x00007f4431ee08b0 0x00007f4431eeffe8 Yes (*) /lib/libgcc_s.so.1
我将更具体地说明什么以及为什么对我不起作用：
- LD_LIBRARY_PATH可以指定相对路径当前工作目录的路径。这不符合我的需求，因为我需要相对于可执行文件位置的相对路径
- RPATH 与 $ORIGIN 旨在成为相对于可执行文件位置的相对路径。但它不符合我的需求，因为当我尝试进行核心分析时它会扩展为绝对路径。
那么如何指定共享库相对于可执行文件位置的相对路径呢？
Is it possible to specify relative paths for shared libraries when I do core analysis (I would like to specify relative paths at compile time instead of debug time)
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007f4433ffef00 0x00007f443402cc08 Yes (*) /lib/libssl.so.0.9.8
0x00007f44334d6a00 0x00007f44335e9920 Yes /lib/libc.so.6
0x00007f443423eaf0 0x00007f4434257994 Yes /lib64/ld-linux-x86-64.so.2
No ./lib/myplugin.so
No /opt/lib/mylibc.so
0x00007f443237a190 0x00007f443237d7f8 Yes /lib/librt.so.1
0x00007f44320f8ef0 0x00007f44321392d8 Yes /lib/libm.so.6
0x00007f4431ee08b0 0x00007f4431eeffe8 Yes (*) /lib/libgcc_s.so.1
I will be more specific about what and why does not work for me:
- LD_LIBRARY_PATH can specify relative path in respect to Current Working Directory. This does not fit my needs because I need relative path in respect to location of executable
- RPATH with $ORIGIN is intended to be relative path in respect to location of executable. But it does not fit my needs because it expands to absolute path when I try to do core analysis.
So how can I specify relative path for shared libraries in respect to location of executable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看来 GDB 7.2 目前不尊重 RPATH。
关于此问题有两个错误：
http://sourceware.org/bugzilla/show_bug.cgi?id=12250
http://sourceware.org/bugzilla/show_bug.cgi?id=12249
It seems that GDB 7.2 currently does not respect RPATH.
There are two bugs opened regarding this issue:
http://sourceware.org/bugzilla/show_bug.cgi?id=12250
http://sourceware.org/bugzilla/show_bug.cgi?id=12249
通常，共享库路径在链接期间并不重要（除非您使用 rpath，它将库路径保留在共享库本身中）。
当程序运行或调试时，会在 shell 变量
LD_LIBRARY_PATH和/etc/ld.so.conf(/etc /ld.so.conf.d/）。LD_LIBRARY_PATH的优先级高于ld.so.conf。export LD_LIBRARY_PATH=../path/to/my/lib1:/path2
使用相对路径没有问题，它也可以工作
程序库指南
Normally the shared libraries paths don't matter during linking time (unless you're using
rpath, that keeps the library path in the shared library itself).When the program is run or debug, the shared libraries are searched in the paths set in shell variable
LD_LIBRARY_PATHand/etc/ld.so.conf(/etc/ld.so.conf.d/).LD_LIBRARY_PATHis with higher priority thanld.so.conf.export LD_LIBRARY_PATH=../path/to/my/lib1:/path2
It's no problem to use relative path, it will work as well
Program Library HOWTO