How to load extra libraries for GDB?

Question

I'm trying to debug a CUDA program, but when I'm launching gdb like so:

$ gdb -i=mi <program name>
$ r <program arguments>

I'm getting:

/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw: 
error while loading shared libraries: libcudart.so.5.0: 
cannot open shared object file: No such file or directory

Process gdb-inferior killed

(formatted for readability)

(I'm running gdb using M-xgdb) If that matters, then CUDA libraries are in the .bashrc

export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"

Solution 1

error while loading shared libraries: libcudart.so.5.0

This error has nothing to do with GDB: your executable, when run from inside GDB, can't find the library it needs.

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"

GDB runs your program in a new $SHELL, so that should have worked. I wonder if there is some interaction with emacs.

In any case, this:

(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run

should fix this problem.

Update:

as I've mentioned it before, ld path is set properly

No, it isn't. If it was, you wouldn't have the problem.

Now, I don't know why it isn't set properly. If you really want to find out, start by running GDB outside emacs (to exclude possible emacs interactions).

If the problem is still present, gdb show env, shell env, adding echo "Here" to your ~/.basrc, etc. should help you find where things are not working as you expect them.

Solution 2

I've had this problem as well. One way to look at it is that even if the LD_LIBRARY_PATH variable is correct when you enter show env into gdb, it may not be correct when you actually execute the program because gdb executes $SHELL -c <program> to run the program. Try this as a test, run $SHELL from the command line and then echo $LD_LIBRARY_PATH. Is it correct? If not, then you probably need to add it to your rc (.tcshrc in my case).

Solution 3

I had a similar problem when trying to run gdb on windows 7. I use MobaXterm to access a Linux toolbox. I installed gdb separately from http://www.gnu.org/software/gdb/ . I got it to work by making sure gdb could find the correct .dll files as mentioned by Employed Russian. If you have MobaXterm installed the .dll files should appear in your home directory in MobaXterm/slash/bin.

gdb however did not recognize the LD_LIBRARY_PATH variable. For me, it worked when I used the PATH variable instead:

    (gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
    (gdb) run

I would think using PATH instead of LD_LIBRARY_PATH might work for you provided you put the correct path to your library.

Solution 4

gdb is looking for a library, so why are you concerned with the include path? You may want to try to set the gdb option "solib-search-path" to point to the location of the libcudart.so.5.0 library.

View more solutions

Comments

[anoneironaut]

Just to get past the obvious. Are you certain that the library you want is in that directory? Are you certain that you are building a 64 bit application? Are the permissions set correctly? And I'm guessing you are able to run this when you don't use GDB?

[jww]

The export trick works on OS X with DYLD_LIBRARY_PATH, too. set env did not work on OS X.

[user1411349]

This is a great tip. We've found great success with unsetting $SHELL prior to launch to avoid this problem. You can do this just for gdb by using env e.g. $ env --unset=SHELL LD_LIBRARY_PATH=/your/path gdb