[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclibc
Subject:    Use executable's RPATH in looking up library searching path.
From:       vapier () gentoo ! org (Mike Frysinger)
Date:       2011-09-29 1:02:32
Message-ID: 201109282102.32775.vapier () gentoo ! org
[Download RAW message or body]

On Tuesday, September 27, 2011 08:04:27 Filippo ARCIDIACONO wrote:
> From Mike Frysinger
> > On Fri, Sep 23, 2011 at 11:23, Filippo ARCIDIACONO wrote:
> > > The ELF spec says what is the RPATH, but nothing about the dynamic
> > > linker Use the rpath in library search path.
> > 
> > i'm afraid this appears to be incorrect.  when i read the
> > spec, it sounds to me like the glibc behavior is wrong and
> > uClibc is right.
> > 
> > note that while the spec says DT_RUNPATH below and not
> > DT_RPATH, the behavior is the same in this regard.  the only
> > difference between DT_RUNPATH and DT_RPATH is precedence wrt
> > $LD_LIBRARY_PATH.
> > 
> > on to the spec (everything below) !
> 
> I already read this spec, but unfortunately it was very old.

the latest changes went in 19 Oct 2010.  how recent does it need to be ?? :p

> I also knew that this could be solved using ldsoconfig,
> LD_LIBRARY_PATH ...., but I wonder if it could be worth fix
> in the Dynamic Linker.
> Finally, I agreed with you, being also the DT_RPATH's use
> superseded by DT_RUNPATH, as the spec says, the DL works fine
> and the fix is useless.

i've come across a case where glibc works the same as uClibc

kmail has custom rpath and needs libkmailprivate, and it is found via the 
custom rpath.  but libkmailprivate needs libmailprivate, but it is found via 
the normal paths ... the custom rpath is not considered.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20110928/6c9901d0/attachment.asc>

[prev in list] [next in list] [prev in thread] [next in thread]