Relative path for shared libraries when analysing core dumps
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
开发者_StackOverflow中文版 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?
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
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_PATH
and /etc/ld.so.conf
(/etc/ld.so.conf.d/
). LD_LIBRARY_PATH
is with higher priority than ld.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
精彩评论