From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Matt Welsh , gdb@sourceware.cygnus.com Subject: Re: Problem with LD_LIBRARY_PATH and gdb 4.18 Date: Wed, 01 Sep 1999 22:55:00 -0000 Message-id: <990902055526.ZM18188@ocotillo.lan> References: <199909020352.UAA23561@bhikku.CS.Berkeley.EDU> X-SW-Source: 1999-q3/msg00279.html 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 To: Kevin Buettner Cc: Matt Welsh , 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> <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 To: Richard Cownie 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: 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 > >