Quantcast

Use executable's RPATH in looking up library searching path.

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Use executable's RPATH in looking up library searching path.

Filippo ARCIDIACONO
I all,
When the dynamic linker load and resolve the library dependencies for an executable,
It should use the executable's rpath as searching path for all his needed libraries.
Follow a minimal test spotting this issue:

--------------------------------
root@arcidiaf:/home/filippo/rpath-test# cat main_app.c
extern int funca(const char *);

int
main ()
{

   funca("main_app");

   return 0;
}
root@arcidiaf:/home/filippo/rpath-test# cat liba.c
#include <stdio.h>

extern int funcb(const char *);

int
funca (const char *st)
{

   printf ("funca called! From %s.\n", st);
   funcb("funca");

   return 0;
}
root@arcidiaf:/home/filippo/rpath-test# cat libb.c
#include <stdio.h>

int
funcb (const char *st)
{

   printf ("funcb called! From %s.\n", st);

   return 0;
}

gcc -Wall -shared -z def -o libb.so -fPIC -D_GNU_SOURCE libb.c
gcc -Wall -shared -z def -o liba.so -fPIC -D_GNU_SOURCE liba.c -L. -lb
gcc -Wall -o main_app -D_GNU_SOURCE -Wl,-rpath,/home/filippo/rpath-test main_app.c -L. -la

root@arcidiaf:/home/filippo/rpath-test# ./main_app
./main_app: can't load library 'libb.so'
------------------------------------

The problem is, when the DL try to find the libb.so (as dependence of liba.so) it searches in
The RPATH of the libray itself (liba.so) that is not set, then in the LD_LIBRARY_PATH
At the end in the systems lib path, without success.
To note the glibc use the executable rpath in his library search path, other reference
Where this is hilight is http://wiki.debian.org/RpathIssue.
The following patch fixes this problem adding the executable's rpath in library search path.

Regards,
Filippo Arcidiacono

From 24f2c2bbc2d8f3b0fbdc27dfc7018141f36e46ab Mon Sep 17 00:00:00 2001
From: Filippo Arcidiacono <[hidden email]>
Date: Wed, 21 Sep 2011 15:00:54 +0200
Subject: [PATCH] ldso: Use the executable's RPATH as library searching path

Signed-off-by: Filippo Arcidiacono <[hidden email]>
---
 ldso/ldso/dl-elf.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/ldso/ldso/dl-elf.c b/ldso/ldso/dl-elf.c
index c28e175..f998aea 100644
--- a/ldso/ldso/dl-elf.c
+++ b/ldso/ldso/dl-elf.c
@@ -234,6 +234,17 @@ struct elf_resolve *_dl_load_shared_library(int secure, struct dyn_elf **rpnt,
  if ((tpnt1 = search_for_named_library(libname, secure, pnt, rpnt)) != NULL)
  return tpnt1;
  }
+
+ /*
+ * Try the DT_RPATH of the executable itself.
+ */
+ pnt = (char *) _dl_loaded_modules->dynamic_info[DT_RPATH];
+ if (pnt) {
+ pnt += (unsigned long) _dl_loaded_modules->dynamic_info[DT_STRTAB];
+ _dl_if_debug_dprint("\tsearching exe's RPATH='%s'\n", pnt);
+ if ((tpnt1 = search_for_named_library(libname, secure, pnt, rpnt)) != NULL)
+ return tpnt1;
+ }
 #endif
 
  /* Check in LD_{ELF_}LIBRARY_PATH, if specified and allowed */
--
1.5.5.6


_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

Laurent Bercot-4
> gcc -Wall -shared -z def -o libb.so -fPIC -D_GNU_SOURCE libb.c
> gcc -Wall -shared -z def -o liba.so -fPIC -D_GNU_SOURCE liba.c -L. -lb
> gcc -Wall -o main_app -D_GNU_SOURCE -Wl,-rpath,/home/filippo/rpath-test main_app.c -L. -la
>
> root@arcidiaf:/home/filippo/rpath-test# ./main_app
> ./main_app: can't load library 'libb.so'
> ------------------------------------

 I would absolutely expect that behaviour.
 If you also link your executable with -lb, you should not have this problem.

 Maybe it's the static linking advocate in me speaking, but I have always
felt that handling dependencies when linking libraries instead of when linking
executables was a recipe for trouble.

--
 Laurent
_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Use executable's RPATH in looking up library searching path.

Filippo ARCIDIACONO
 

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Laurent Bercot
> Sent: Thursday, September 22, 2011 5:53 PM
> To: [hidden email]
> Subject: Re: Use executable's RPATH in looking up library
> searching path.
>
> > gcc -Wall -shared -z def -o libb.so -fPIC -D_GNU_SOURCE libb.c gcc
> > -Wall -shared -z def -o liba.so -fPIC -D_GNU_SOURCE liba.c
> -L. -lb gcc
> > -Wall -o main_app -D_GNU_SOURCE -Wl,-rpath,/home/filippo/rpath-test
> > main_app.c -L. -la
> >
> > root@arcidiaf:/home/filippo/rpath-test# ./main_app
> > ./main_app: can't load library 'libb.so'
> > ------------------------------------
>
>  I would absolutely expect that behaviour.
>  If you also link your executable with -lb, you should not
> have this problem.

The application use a function defined in liba, no need to link the libb.
In any case even if the libb is needed by the app, the problem is the same.
The error message is refering when the DL analizing the dependencies of liba
And it use the library search path to found the needed libraries, then even
if libb has been previously loaded as dependencies of application it cannot
find.


>
>  Maybe it's the static linking advocate in me speaking, but I
> have always felt that handling dependencies when linking
> libraries instead of when linking executables was a recipe
> for trouble.
>
> --
>  Laurent
> _______________________________________________
> uClibc mailing list
> [hidden email]
> http://lists.busybox.net/mailman/listinfo/uclibc
>

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

Mike Frysinger
In reply to this post by Filippo ARCIDIACONO
On Thursday, September 22, 2011 11:39:24 Filippo ARCIDIACONO wrote:
> When the dynamic linker load and resolve the library dependencies for an
> executable, It should use the executable's rpath as searching path for all
> his needed libraries.

i don't see any justification to back up this statement other than "this is
what glibc does".  i'm honestly not too concerned by that as there are places
already we deviate from glibc behavior by design.  what i do want to know is
what the ELF spec says.  could you look that up (i dont have a copy off hand
and the LF is down still) ?
-mike

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Use executable's RPATH in looking up library searching path.

Filippo ARCIDIACONO
 

> -----Original Message-----
> From: Mike Frysinger [mailto:[hidden email]]
> Sent: Friday, September 23, 2011 4:40 PM
> To: [hidden email]
> Cc: Filippo ARCIDIACONO
> Subject: Re: Use executable's RPATH in looking up library
> searching path.
>
> On Thursday, September 22, 2011 11:39:24 Filippo ARCIDIACONO wrote:
> > When the dynamic linker load and resolve the library
> dependencies for
> > an executable, It should use the executable's rpath as
> searching path
> > for all his needed libraries.
>
> i don't see any justification to back up this statement other
> than "this is what glibc does".  i'm honestly not too
> concerned by that as there are places already we deviate from
> glibc behavior by design.  what i do want to know is what the
> ELF spec says.  could you look that up (i dont have a copy
> off hand and the LF is down still) ?

The ELF spec says what is the RPATH, but nothing about the dynamic linker
Use the rpath in library search path.
Other references are not so clear. The only reference (apart from glibc
sources)
I found is http://wiki.debian.org/RpathIssue where seems clear to use the
executable's
Rpath as searching path for needed libraries.

> -mike
>

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

Mikhail Gusarov-3
In reply to this post by Mike Frysinger

Twas brillig at 10:40:06 23.09.2011 UTC-04 when [hidden email] did gyre and gimble:

 MF> i don't see any justification to back up this statement other than
 MF> "this is what glibc does".  i'm honestly not too concerned by that
 MF> as there are places already we deviate from glibc behavior by
 MF> design.  what i do want to know is what the ELF spec says.  could
 MF> you look that up (i dont have a copy off hand and the LF is down
 MF> still) ?

As a matter of anecdote, BSD linkers don't use executable's RPATH in
this situation.

--
  http://fossarchy.blogspot.com/

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

chickenandporn
On Fri, Sep 23, 2011 at 11:45, Mikhail Gusarov <[hidden email]>wrote:

>
> Twas brillig at 10:40:06 23.09.2011 UTC-04 when [hidden email] did gyre
> and gimble:
>
>  MF> i don't see any justification to back up this statement other than
>  MF> "this is what glibc does".  i'm honestly not too concerned by that
>  MF> as there are places already we deviate from glibc behavior by
>  MF> design.  what i do want to know is what the ELF spec says.  could
>  MF> you look that up (i dont have a copy off hand and the LF is down
>  MF> still) ?
>
> As a matter of anecdote, BSD linkers don't use executable's RPATH in
> this situation.
>

config option?

As a past embedded guy, I like the idea of this being around as a way to fix
dependency issues based on how developers are accustomed to coding on common
platforms.

Allan

--
[hidden email]  "金鱼" http://linkedin.com/in/goldfish
_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

Mike Frysinger
On Friday, September 23, 2011 15:39:38 Allan Clark wrote:
> As a past embedded guy, I like the idea of this being around as a way to
> fix dependency issues based on how developers are accustomed to coding on
> common platforms.

you can also trivially make it work with other knobs: ld.so.conf, LD_PRELOAD,
LD_LIBRARY_PATH, etc...
-mike

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

Mike Frysinger
In reply to this post by Filippo ARCIDIACONO
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) !

http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#shobj_dependencies

The set of directories specified by a given DT_RUNPATH entry is used
to find only the immediate dependencies of the executable or shared
object containing the DT_RUNPATH entry. That is, it is used only for
those dependencies contained in the DT_NEEDED entries of the dynamic
structure containing the DT_RUNPATH entry, itself. One object's
DT_RUNPATH entry does not affect the search for any other object's
dependencies.
-mike
_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Use executable's RPATH in looking up library searching path.

Filippo ARCIDIACONO
 

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Mike Frysinger
> Sent: Saturday, September 24, 2011 8:46 AM
> To: Filippo ARCIDIACONO
> Cc: [hidden email]
> Subject: Re: Use executable's RPATH in looking up library
> searching path.
>
> 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.
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.

>
> http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#sho
> bj_dependencies
>
> The set of directories specified by a given DT_RUNPATH entry
> is used to find only the immediate dependencies of the
> executable or shared object containing the DT_RUNPATH entry.
> That is, it is used only for those dependencies contained in
> the DT_NEEDED entries of the dynamic structure containing the
> DT_RUNPATH entry, itself. One object's DT_RUNPATH entry does
> not affect the search for any other object's dependencies.
> -mike
>

Filippo.

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Use executable's RPATH in looking up library searching path.

Mike Frysinger
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

_______________________________________________
uClibc mailing list
[hidden email]
http://lists.busybox.net/mailman/listinfo/uclibc

signature.asc (853 bytes) Download Attachment
Loading...