Re: Gdb LD_LIBRARY_PATH Problem

[Richard Earnshaw <rearnsha@arm.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.