[Bug cli/15190] New: programs run inside gdb ignore LD_LIBRARY_PATH

[lvernschrock at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15190

Bug #: 15190
Summary: programs run inside gdb ignore LD_LIBRARY_PATH
Product: gdb
Version: 7.2
Status: NEW
Severity: normal
Priority: P2
Component: cli
AssignedTo: ***@sourceware.org
ReportedBy: ***@gmail.com
Classification: Unclassified


This looks very similar to bug # 9011. I think that the easiest way to discuss
this is to simply paste my shell output in the bug report:
[quote]

void printmessage();
EOF
#include "awsome.h"
#include <stdio.h>
void printmessage(){
printf("your computer is awsome\n");
}
EOF
#include "awsome.h"
int main(int argv){
printmessage();
return 0;
}
EOF

***@box:~$ gcc -c demo.c -o demo.o
***@box:~$ gcc demo.o -Lmylib -lawsome -o demo
***@box:~$ ./demo
./demo: error while loading shared libraries: libawsome.so: cannot open shared
object file: No such file or directory
***@box:~$ export LD_LIBRARY_PATH=~/mylib
***@box:~$ ./demo
your computer is awsome
***@box:~$ gdb demo
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/tc/demo...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/tc/demo
/home/tc/demo: error while loading shared libraries: libawsome.so: cannot open
shared object file: No such file or directory

Program exited with code 0177.
(gdb) show env LD_LIBRARY_PATH
LD_LIBRARY_PATH = /home/tc/mylib
(gdb) quit
[/quote]
What really bothers me is the output from "show env LD_LIBRARY_PATH".
It seems that gdb sees the environmental variable; why can't the program inside
see it?
I'm running on a Linux-based O.S.; kernel version 3.0.21.

P.S. I don't actually want to debug this demo program. I'm trying to debug a
more complex program and I wrote this trivial example to illustrate the issue
I'm running into.

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15190

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
CC| |jan.kratochvil at redhat
| |dot com

--- Comment #1 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2013-02-26 15:39:10 UTC ---
Not reproducible for me (Fedora 17 x86_64):

$ echo $LD_LIBRARY_PATH
/home/jkratoch/t/mylib
$ /tmp/gdb-7.2/gdb/gdb demo
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/jkratoch/t/demo...(no debugging symbols
found)...done.
(gdb) show env LD_LIBRARY_PATH
LD_LIBRARY_PATH = /home/jkratoch/t/mylib
(gdb) run
Starting program: /home/jkratoch/t/demo
your computer is awsome

Program exited normally.
(gdb) q

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15190

Pedro Alves <palves at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> 2013-02-26 20:18:22 UTC ---
Could it be something in your shell's config clearing the environment?

GDB runs the program like "exec $SHELL -c program".

[lvernschrock at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15190

lvernschrock at gmail dot com changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |DUPLICATE

--- Comment #3 from lvernschrock at gmail dot com 2013-02-27 15:01:26 UTC ---
Okay, it is defiantly a problem with my shell configuration.

[quote]
***@box:~$ export LD_LIBRARY_PATH=/home/tc/mylib
***@box:~$ echo $LD_LIBRARY_PATH
/home/tc/mylib
***@box:~$ $SHELL
***@box:~$ echo $LD_LIBRARY_PATH

***@box:~$ exit
***@box:~$ echo $LD_LIBRARY_PATH
/home/tc/mylib
[/quote]

Thus I assume that this is an invalid bug. I'll mark it as a duplicate of bug#
9011.

*** This bug has been marked as a duplicate of bug 9011 ***

[trevorboydsmith at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15190

T.S. <trevorboydsmith at gmail dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |trevorboydsmith at gmail dot com

--- Comment #4 from T.S. <trevorboydsmith at gmail dot com> ---
I also ran into the same issue. I wanted to leave this comment here to help
future users.

---

In my case, I was using Eclipse-CDT which runs `gdb`.

Running the program from Eclipse worked fine... but trying to use Eclipse to
debug the program is where I ran into this specific issue.

I tried to fix the issue by doing `export
LD_LIBRARY_PATH="/path/to/libraries:${LD_LIBRARY_PATH}"` and then starting
Eclipse... but then I got the "cannot open shared object" error message.

Then I ran across this post and I tried recreating the error on the interactive
command line by doing `exec $SHELL -c executable_path` and saw the same error
message that Eclipse was emitting when I tried to use the debugger.

I was using tcsh as the default SHELL with a heavily modified environment that
I did not configure (apparently the environment must have cleared the
LD_LIBRARY_PATH or something).

My fix was to do an `export SHELL=/bin/bash` then start Eclipse and now
debugging worked.

Alternatively I could have fixed my tcsh shell but I haven't done that so far
because the environment setup scripts are extensive (I could probably just do
an `setenv LD_LIBRARY_PATH` in my home .tcshrc but I did not test that yet).