Gdb LD_LIBRARY_PATH Problem
Richard Earnshaw
rearnsha@arm.com
Thu Dec 12 07:51:00 GMT 2002
> 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.
More information about the Gdb
mailing list