I've already read gdb says "cannot open shared object file" and gdb can not open shared object file and followed the instructions.
I have a binary which is linked to a shared library file (/zzz/yyy/xxx.so). After I set LD_LIBRARY_PATH to /zzz/yyy/ and run the binary without GDB, it executes very well.
However, when I was trying to use GDB to debug this binary, GDB says:
error while loading shared libraries: xxx.so: cannot open shared object file: No such file or directory
I already have (set in .gdbinit):
(gdb)show env LD_LIBRARY_PATH
LD_LIBRARY_PATH = "/zzz/yyy/"
and
(gdb) show solib-search-path
The search path for loading non-absolute shared library symbol files is "/zzz/yyy/".
and in my system:
% printenv LD_LIBRARY_PATH
/zzz/yyy
What's the other possible reasons why GDB still can't find this shared library?
However, when I was trying to use GDB to debug this binary, GDB says: error while loading shared libraries: xxx.so: cannot open shared object file: No such file or directory
You are mistaken: it's not GDB that says that, it's the dynamic loader. GDB itself doesn't care what LD_LIBRARY_PATH is set to, it simply runs your program. But your program can not run.
The most common cause: you are re-setting your LD_LIBRARY_PATH in your ~/.cshrc, and GDB runs your program in a separate shell, and that shell reads your .cshrc, so your program executes with incorrect environment.
The fix is to make .cshrc not set LD_LIBRARY_PATH for non-interactive shells. See e.g. this answer.
Related
I have a crash dump that I want to analyse with GDB on different computer. Crashed application uses several shared libraries (*.so files). I want GDB to load symbols from some of them but I can't put all of them in the original path.
Adding LD_LIBRARY_PATH to the environment doesn't help when working with dumps. When I type info shared it shows full (non-relative) paths:
(gdb) info shared
From To Syms Read Shared Object Library
0x00007fad4fb7f220 0x00007fad4fb80179 Yes /lib/x86_64-linux-gnu/libdl.so.2
...
No /opt/app/libXXX.so
...
How to specify different path for the example libXXX.so (from gdb command line or command prompt)?
The set solib-search-path option is for that purpose. Documentation says it is ment for using with gdbserver but also works with dump analysis. By default, it is set to ., so the directory that gdb is run from.
BUT: for some reason it doesn't work out of the box (at least with gdb 10.2). I don't know the reason, but I know a workaround: just type set solib-search-path . as a first command after entering gdb prompt. The output is following for me:
(gdb) set solib-search-path .
Reading symbols from /home/example/path/libXXX.so...
Of course one can type any path she want instead of ..
I'm repeatedly experiencing problems with libraries which are not found.
In my bashrc I have:
LD_LIBRARY_PATH=
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib1
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib2
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib3
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
These paths contain ALL folders from where I link libraries into my program with -L/lib1 -l1a -L/lib2 -l2a -L/lib3 -l3a.
Now I start my program standalone:
./program
Fine!
Then I start it with mpiexec from mpich:
/mpich/intel/bin/mpiexec -np 2 ./solvertest1
Fine!
BUT THEN I start it with gdb enabled:
/mpich/intel/bin/mpiexec -np 2 gdb ./solvertest1
Problem, libraries are not found:
Starting program: /my/program
/my/program: error while loading shared libraries: libirng.so: cannot open shared object file: No such file or directory
I suspect that there's something wrong when the LD_LIBRARY_PATH should be propagated through all the subprocesses and shells those scripts and programs produce... What do I have to do to let every subprocess (and whatever else will be started) know where those libraries are?
Store the library path in the DT_RPATH tag of your executable when linking
-Wl,rpath=/lib1 -Wl,rpath=/lib2 -Wl,rpath=/lib3
that way you don't need to mess with LD_LIBRARY_PATH and shell initialization.
Since the program is dependent on having the right environment variables set to run, and mpiexec isn't giving it the env it needs, try something like these from the mpiexec docs:
-x , --envall
Export all environment variables to all processes.
-E , --env name value
Export the variable name with the content value.
While running the application developed by other person, getting the following error
./appln: error while loading shared libraries: libxerces-c.so.28: cannot open shared object file: No such file or directory
And if I run ldd command:
# ldd appln
linux-gate.so.1 => (0x00e20000)
libdl.so.2 => /lib/libdl.so.2 (0x00a61000)
libxerces-c.so.28 => not found
I already have that libxerces-c.so.28 file in current folder. Please help me how to resolve that error
You need to put libxerces-c.so somewhere in the library path. Probably current folder is not searched for libraries. Try putting it in /usr/local/lib
Evidently "the current folder" isn't in the run time search path used by your executable. I'm assuming that you are on linux (linux-gate.so.1).
You need to ensure that "the current" directory is under the search path. You can do this at link time by using the -rpath option to the linker (-R is also accepted) or -Wl,-rpath,<dir> if you are invoking the linker through the compiler front end. This embeds a search path to be used at run time into your program.
Consider how you want the program to be installed, though. There's no point in adding a path that is specific to your development environment. You might want to consider using $ORIGIN or a $ORIGIN relative path which tells the run time linker to look for shared objects in the location containing (or relative to) the executable. You should always avoid adding . to the run time search path; your program shouldn't behave differently depending on the current directory of the process which invokes it.
As a temporary measure you can set the environment variable LD_LIBRARY_PATH to override the embedded and system search paths but it is normally a bad idea to rely on LD_LIBRARY_PATH overrides for a final installation.
By default .so files are NOT being searched in the current folder (they should be in /usr/lib, etc).
To add the current directory for .so lookup use:
LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ./appln
When adding new "local system" libraries (e.g. in /usr/local/lib/) you better add that directory (/usr/local/lib/) once in your /etc/ld.so.conf and you should run ldconfig to update the linker cache (every time you add something inside /usr/local/lib/)
See ldconfig(8), ld.so(8), ldd(1), dlopen(3)
If you want your own libraries, set LD_LIBRARY_PATH to a directory containing them (e.g. $HOME/lib/ and to standard directories, e.g.
export LD_LIBRARY_PATH=$HOME/lib:/usr/lib:/usr/local/lib
in your ~/.bashrc (but I dislike that confusing practice, and prefer to manage my /usr/local/lib/).
You could also use some -Wl,-rpath argument but I really dislike that also.
Read also Program Library HowTo and Drepper's paper: How To Write Shared Libraries
I work on program with multiple C++ files. I have run the executable through gdb for debugging segmentation fault. Later, gdb backtrace provided the list of functions before segmentation fault. Later, I tried to set a break point in a file on a particular line-number. (The path specified is absolute path)
(gdb) break /aia/r015/home/sathish/zfs_amr/src/zfslbminterfaced2q9.cpp:100
However, gdb gives the following message:
No source file named /aia/r015/home/sathish/zfs_amr/src/zfslbminterfaced2q9.cpp.
However, this particular does exist in the location. What really the message means?
What really the message means?
The message means that GDB does not know about any source file named /aia/r015/home/sathish/zfs_amr/src/zfslbminterfaced2q9.cpp.
There are multiple reasons this could be the case:
The debug info for this file is missing, either because that file is compiled without -g, or because the debug info was (possibly inadvertantly) stripped later on,
There are some symbolic links in the above path, and GDB knows that file by fully-resolved pathname instead,
The file is actually not linked into the executable at all,
The file part of a shared library, and symbols for that shared library haven't been loaded yet,
Etc.
As Pat suggested, setting breakpoint on zfslbminterfaced2q9.cpp:100 is more likely to work.
If that doesn't work, info sources will tell you which files GDB does know about.
Update:
info sources gives blank
This means that the application doesn't have any debug info at all.
Usually this happens for one of two reasons:
You neglected to specify -g on the link line (some platforms require -g both at compile and link time),
You have a "stray" -s somewhere on your link line (which strips the final executable).
I am running my first program in ubuntu.
But there was an error when I tried to run it:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no foo in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1681)
at java.lang.Runtime.loadLibrary0(Runtime.java:840)
at java.lang.System.loadLibrary(System.java:1047)
at JNIFoo.<clinit>(JNIFoo.java:6)
Could not find the main class: JNIFoo. Program will exit.
These lines taken from Getting Stated JNI from SUN site
Make sure that the native library resides in one of the directories in
the native library path. If you are running on a Solaris system, the
LD_LIBRARY_PATH environment variable is used to define the native
library path. Make sure that it includes the name of the directory
that contains the libHelloWorld.so file. If the libHelloWorld.so file
is in the current directory, you can issue the following two commands
in the standard shell (sh) or KornShell (ksh) to set up the
LD_LIBRARY_PATH environment variable properly:
LD_LIBRARY_PATH=.
export LD_LIBRARY_PATH
Exception in thread "main" java.lang.UnsatisfiedLinkError: no foo in java.library.path
Fix your library path and try again.