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

Filippo ARCIDIACONO filippo.arcidiacono at st.com
Thu Sep 22 16:10:16 UTC 2011


 

> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Laurent Bercot
> Sent: Thursday, September 22, 2011 5:53 PM
> To: uclibc at uclibc.org
> 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 at 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
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 



More information about the uClibc mailing list