Gdb LD_LIBRARY_PATH Problem

Gdb LD_LIBRARY_PATH Problem

[Max]

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 ?

Max.

Gdb : gdb-5.0-148
Suse 7.3, i386

Re: Gdb LD_LIBRARY_PATH Problem

[Roland Egger]

Hi,
hmm I used the LD_LIBRARY_PATH several times with
gdb and it worked.
How did you see that the LD_LIBRARY_PATH is correct before
the last lib? Did you need it before or is the LD_LIBRARY_PATH
only needed for the last library?
I think you haven't made a mistake by setting the LD_LIBRARY_PATH
but perhaps you can check again if you set it for e.g. lib is in
/home/test/opt/lib

csh compatible shells with
setenv LD_LIBRARY_PATH /home/test/opt/lib

or for bourne shell compatible shells

LD_LIBRARY_PATH=/home/test/opt/lib
export LD_LIBRARY_PATH

Perhaps that could help?

Bye
   Roland


On Thu, Dec 12, 2002 at 02:41:42PM +0100, Max wrote:
> 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 ?
> 
> Max.
> 
> Gdb : gdb-5.0-148
> Suse 7.3, i386
> 
> 
> 

Re: Gdb LD_LIBRARY_PATH Problem

[Richard Earnshaw]

> 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.