Problem with LD_LIBRARY_PATH and gdb 4.18

Problem with LD_LIBRARY_PATH and gdb 4.18

[Matt Welsh]

I'm using gdb 4.18 (although 4.16 exhibits the same problem) on a Linux x86
machine with glibc 2.1.1 (Red Hat 6.0). gdb fails to run any binaries which
require shared libraries not on the usual search path for ld.so, i.e. any
libraries located by LD_LIBRARY_PATH.

Setting LD_LIBRARY_PATH or gdb 'set solib-search-path' has no effect. Here
is what I see:

> enclave1:~/src/ninja/test/mdw% echo $LD_LIBRARY_PATH
> /home/cs/mdw/lib:/usr/local/ninja/gcc-2.95.1/lib
> enclave1:~/src/ninja/test/mdw% gdb TestT
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...
> (gdb) run   
> Starting program: /disks/now/grad/mdw/src/ninja/test/mdw/TestT 
> /disks/now/grad/mdw/src/ninja/test/mdw/TestT: error in loading shared libraries: libgcj.so.0: cannot open shared object file: No such file or directory
>
> Program exited with code 0177.

In this case, libgcj.so.0 is found in the LD_LIBRARY_PATH. I can run the
program just fine directly from the shell, but not from within gdb.

I can 'attach' to the running process from gdb, however, in some cases I 
wish to test the code as it's starting, so this is not good enough.

If I set LD_LIBRARY_PATH and run 'strace TestT' from within gdb, it's
obvious that ld.so is not looking for the library in any directories on the
LD_LIBRARY_PATH. Is it possible that gdb is not passing along the value of
this environment variable?

Thanks much,
Matt Welsh, mdw@cs.berkeley.edu

Re: Problem with LD_LIBRARY_PATH and gdb 4.18

[Kevin Buettner]

Matt,

This is very odd.  I am presently debugging a problem in gdb (on a Red
Hat 6.0 machine) which is shared library related and am having no
trouble with LD_LIBRARY_PATH.  I am using gdb-4.18.1 (the head of the
Cygnus development tree), but have also tried it with gdb-4.17.0.11
which ships with Red Hat 6.0 after reading your report below.

What does ldd show you?  Does naming the library somewhat differently
make any difference?  (I.e, what happens if you name it libgcj.so or
create a symlink to libgcj.so.0?)

Another thing you might try is the command

	show env LD_LIBRARY_PATH

from within gdb to make sure that gdb knows about this environment
variable.

Regards,

Kevin

On Sep 1,  8:52pm, Matt Welsh wrote:
> Subject: Problem with LD_LIBRARY_PATH and gdb 4.18
> 
> I'm using gdb 4.18 (although 4.16 exhibits the same problem) on a Linux x86
> machine with glibc 2.1.1 (Red Hat 6.0). gdb fails to run any binaries which
> require shared libraries not on the usual search path for ld.so, i.e. any
> libraries located by LD_LIBRARY_PATH.
> 
> Setting LD_LIBRARY_PATH or gdb 'set solib-search-path' has no effect. Here
> is what I see:
> 
> > enclave1:~/src/ninja/test/mdw% echo $LD_LIBRARY_PATH
> > /home/cs/mdw/lib:/usr/local/ninja/gcc-2.95.1/lib
> > enclave1:~/src/ninja/test/mdw% gdb TestT
> > GNU gdb 4.18
> > Copyright 1998 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i386-redhat-linux"...
> > (gdb) run   
> > Starting program: /disks/now/grad/mdw/src/ninja/test/mdw/TestT 
> > /disks/now/grad/mdw/src/ninja/test/mdw/TestT: error in loading shared libraries: libgcj.so.0: cannot open shared object file: No such file or directory
> >
> > Program exited with code 0177.
> 
> In this case, libgcj.so.0 is found in the LD_LIBRARY_PATH. I can run the
> program just fine directly from the shell, but not from within gdb.
> 
> I can 'attach' to the running process from gdb, however, in some cases I 
> wish to test the code as it's starting, so this is not good enough.
> 
> If I set LD_LIBRARY_PATH and run 'strace TestT' from within gdb, it's
> obvious that ld.so is not looking for the library in any directories on the
> LD_LIBRARY_PATH. Is it possible that gdb is not passing along the value of
> this environment variable?
> 
> Thanks much,
> Matt Welsh, mdw@cs.berkeley.edu
> 
>-- End of excerpt from Matt Welsh



-- 
Kevin Buettner
kev@primenet.com, kevinb@cygnus.com
From jsm@cygnus.com Wed Sep 01 23:04:00 1999
From: Jason Molenda <jsm@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Matt Welsh <mdw@cs.berkeley.edu>, gdb@sourceware.cygnus.com
Subject: Re: Problem with LD_LIBRARY_PATH and gdb 4.18
Date: Wed, 01 Sep 1999 23:04:00 -0000
Message-id: <19990901230402.A19637@cygnus.com>
References: <199909020352.UAA23561@bhikku.CS.Berkeley.EDU> <mdw@cs.berkeley.edu> <990902055526.ZM18188@ocotillo.lan>
X-SW-Source: 1999-q3/msg00280.html
Content-length: 633

On Wed, Sep 01, 1999 at 10:55:26PM -0700, Kevin Buettner wrote:

> Another thing you might try is the command
> 
> 	show env LD_LIBRARY_PATH
> 
> from within gdb to make sure that gdb knows about this environment
> variable.


Keep in mind that if you have a .profile or .bashrc (on Linux) and it
sets the LD_LIBRARY_PATH unconditionally, I _believe_ the inferior will
get that .profile L_L_P setting instead of the one you had in gdb.

A lot of people run into this, it is somewhat nonintuitive IMHO.
I haven't thought through the issue in depth, though; I vaguely remember
that other people had a good reason for this behavior.

J
From kip@lyris.com Wed Sep 01 23:12:00 1999
From: Kip Macy <kip@lyris.com>
To: Richard Cownie <tich@ma.ikos.com>
Cc: freebsd-current@freebsd.org, gdb@sourceware.cygnus.com, tich@par28.ma.ikos.com
Subject: Re: gdb-4.17 in FreeBSD 4.0-CURRENT
Date: Wed, 01 Sep 1999 23:12:00 -0000
Message-id: <Pine.SOL.4.05.9909012306460.28347-100000@luna>
References: <99082010412803.11889@par28.ma.ikos.com>
X-SW-Source: 1999-q3/msg00281.html
Content-length: 1368

I tried doing the same on FreeBSD 3.2-STABLE
but when I run it it complains that it is unable to find dynamic linker
breakpoint function and then it stops with a SIGTRAP.
Any ideas what might be wrong?

Thanks.

				-Kip

On Fri, 20 Aug 1999, Richard Cownie wrote:

> I managed to build gdb-4.17 in FreeBSD 4.0, here's how to do it:
> 
> 1) gdb-4.17/configure --host=i386-unknown-freebsdelf4.0
>     Have to specify the host explicitly, otherwise it doesn't realize
>     it needs to use ELF.
> 
> 2) in gdb-4.17/Makefile, add "-DSVR4_SHARED_LIBS" to definition of CFLAGS
> 
> 3) in gdb-4.17/gdb/solib.c, add #include "elf/common.h" 
>     (after #include "elf/external.h")
> 
> 4) in gdb-4.17/gdb/infptrace.c, add #define U_REGS_OFFSET 0x1fa8
>     I figured out this number the hard way by searching all the valid PT_READ_U
>     addresses and comparing the results with PT_GETREGS - found locations
>     where eip and esp values matched up.  Doubtless there's a better way to
>     get the right value.
> 
> Then it should all build (and perhaps work).  The same hacks probably apply
> to gdb-4.18 and gdb-current (but so far gdb-4.17 is the most useful version
> I've seen for debugging C++).
> 
> Richard Cownie (tich@ma.ikos.com)
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 

Re: Problem with LD_LIBRARY_PATH and gdb 4.18

[Matt Welsh]

Jason,

Jason Molenda <jsm@cygnus.com> writes:
> Keep in mind that if you have a .profile or .bashrc (on Linux) and it
> sets the LD_LIBRARY_PATH unconditionally, I _believe_ the inferior will
> get that .profile L_L_P setting instead of the one you had in gdb.

This turned out to be the problem.

On my system, 'tcsh' is my default shell, but my .cshrc execs bash
instead when the shell is interactive (don't ask why). However for
non-interactive shells, the .cshrc is executed which does in fact 
set LD_LIBRARY_PATH to something bogus. I would have never guessed this
to be the problem, since I didn't know gdb spawned a new shell for the
process!

Thanks,
Matt Welsh