CODEWITHSUNDEEP
gdb
GMichael
GMichael

Reputation: 2776

GDB cannot open shared object

I have the problem that was discussed several times here: the application runs when started directly from shell and does not run when I try to start it within the debugger in the same shell. Running inside GDB produces the "cannot open shared object" error.

I've read all the posts and did all the suggestions:

  1. I setup LD_LIBRARY_PATH manually and verified that my application runs and ldd -r passes without errors
  2. I setup solib-search-path and solib-absolute-prefix inside GDB to the same value as LD_LIBRARY_PATH and '/' respectively. All the paths are absolute
  3. I ran GDB with strace to see where GDB looks for the required shared libraries and found that it ignores the list of directories from LD_LIBRARY_PATH / solib-search-path

What can I do?

It's GDB 7.11.1 with RHEL 7

Upvotes: 0

Views: 1088

Answers (1)

Employed Russian
Employed Russian

Reputation: 213375

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.

Upvotes: 2

Related Questions