0

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?

Community
  • 1
  • 1
stanleyli
  • 1,427
  • 1
  • 11
  • 28
  • 2
    In these cases it is useful `strace`. Try running `strace -o out.txt gdb ./myprogram` and then, after the error happens quit the debugger and do `grep xxx.so out.txt` to see where gdb is looking for the library. – rodrigo May 01 '14 at 01:07
  • @rodrigo: Thanks. I realize it's because I have an extra LD_LIBRARY_PATH directory in ~/.cshrc. There is an x64 version library file (my application is built for x86) in that directory. The x64 version file makes the GDB complain. BTW, the strace doesn't seem to work well in this case, it didn't show that GDB has ever tried to access the x64 library (but GDB should have done that). – stanleyli May 02 '14 at 23:20
  • Maybe gdb forked. `strace` by default only traces one process. You can use `strace -f` to trace the child process also and see what happens. – rodrigo May 02 '14 at 23:36

1 Answers1

3

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.

Community
  • 1
  • 1
Employed Russian
  • 199,314
  • 34
  • 295
  • 362