Gdb Can Not Open Shared Object File

gdb can not open shared object file

You can use the set environment command in gdb to change the environment gdb uses to launch the program you want to debug. Extract from the gdb help:

(gdb) help set environment 
Set environment variable value to give the program.
Arguments are VAR VALUE where VAR is variable name and VALUE is value.
VALUES of environment variables are uninterpreted strings.
This does not affect the program until the next "run" command.

Example with LD_LIBRARY_PATH:

(gdb) set environment LD_LIBRARY_PATH /home/paceholder/projects/geo/lib/debug

GDB cannot open shared object file Issue

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.

GDB cannot open shared object

I have the problem

If you do, you've done a very poor job of describing what your problem actually is.

I ran GDB with strace to see where GDB looks for the required shared libraries and found that it ignores the list of directories

GDB doesn't look for any shared libraries until it gets notified by the runtime loader that some shared library has been added to the process.

If you didn't attach to a running inferior, then GDB wouldn't look for any libraries, and you've likely arrived at a completely wrong conclusion.

P.S. GDB doesn't use LD_LIBRARY_PATH at all, and setting either solib-search-path or solib-absolute-prefix is usually not needed either (unless you are doing remote debugging, or analyzing a core that came from a different machine).

Update:

the application runs when started directly from shell and does not run when I try to start it within the debugger

In 99.9% of the cases I've seen, this happens because ~/.bashrc or some such resets LD_LIBRARY_PATH inappropriately. GDB starts a new shell to run the application in, and if that (non-interactive) shell resets the environment, the application may behave differently inside vs. outside of GDB.

The correct solution is to make ~/.bashrc (or whatever shell startup file is appropriate for your shell) to do nothing when running non-interactively.

gdb says cannot open shared object file

Emacs probably does not read your .bashrc before it invokes gdb. Try to put 'set solib-search-path' and 'set solib-absolute-path in your .gdbinit file instead

gdb error while executing compile command: libcc1.so: cannot open shared object file: No such file or directory

Copying the file libcc1.so.0.0.0 as libcc1.so in /usr/lib/x86_64-linux-gnu/ did the trick

load shared lib in GDB session

How can I tell to GDB where this library is located and load it? I am looking for something similar to LD_LIBRARY_PATH, but I want to set it directly from the GDB session.

You can't -- the error is not coming from GDB; it's coming from the dynamic loader.

There are two ways to tell the dynamic loader where to find this library: using -rpath at link time, or setting LD_LIBRARY_PATH environment variable.

If for whatever reason you don't want to set LD_LIBRARY_PATH before invoking GDB, you can do so at the (gdb) prompt using set env command:

(gdb) set env LD_LIBRARY_PATH /dir/where/libshr1/is/located
(gdb) run

P.S. If this doesn't work, your shell might be resetting LD_LIBRARY_PATH inappropriately. See this answer.

GDB Error gdb: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory

The python interpreter is looking for a version of libffi that does not exist on your system. Rebuild the python interpreter and it will look for a version that exists on your system.

yay --rebuild -S python38

Replace python38 with the interpreter used by the program you are calling.

Related:

https://aur.archlinux.org/packages/python38/

Ubuntu 20.04 upgrade, Python missing libffi.so.6

---

Related Topics