This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Gdb LD_LIBRARY_PATH Problem
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Max <listposter at machsim dot com>
- Cc: gdb at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Thu, 12 Dec 2002 15:50:44 +0000
- Subject: Re: Gdb LD_LIBRARY_PATH Problem
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> Hi,
>
> I have an qt application whichis linked against a home made .so file.
> While app runs perfectly in the shell, it is not possible to run it in
> gdb due to the error :
>
> error while loading shared libraries: libDCcom.so
>
> I have gone thru all the posts in the mailing lists and newsgroups and
> google, but I still don't have a solution.
>
> When I do "set env LD_DEBUG=libs", I find something interesting. Gdb
> finds all libraries currently till the last one which is libDCcom.so.
> When gdb starts looking for this, it notices that the application has
> RPATH ( which is correct ) , searches the RPATHS and can not find it
> there which is also correct since the .so is not there, it is in the
> LD_LIBRARY_PATH.
>
> After looking for RPATH, gdb searches thru the LD_LIBRARY_PATH but !!!!
> this time the LD_LIBRARY_PATH is incorrect !!!! For all the searches
> before this shared object, the correct LD_LIBRARY_PATH is used however
> for the last .so , the LD_LIBRARY_PATH is broken.
>
> Can anybody give me a hint ?
A situation like this is often observed by csh users (or any similar
shell). The cause is normally that their .cshrc file sets LD_LIBRARY_PATH
back to a 'well-known' value. Since gdb starts an inferior process by
forking a $SHELL and then letting the shell run the real application you
get whatever LD_LIBRARY_PATH your .cshrc sets.
Setting environment variables in .cshrc is generally a bad idea, since
every subshell gets messed around by this. It's far better to put
environment settings into your .login file.
R.