Re: dlopen/RPATH/RUNPATH

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: dlopen/RPATH/RUNPATH

William K. Foster
Hello,

This doesn't seem right to me.  If I go to the trouble of setting
up an -rpath, why wouldn't you want dlopen() to respect it?

Regardless, if dlopen() is considered correct as is, how could
I query the -rpath at runtime from within the application so that
I can emulate the behavior I desire?  I can get the $ORIGIN by
calling dlopen() on a null filename to get the main application's
path.  But that leaves me wanting the -rpaths I defined relative
to the $ORIGIN.  I imagine using -D flags from the make file,
but there are an indeterminate number of directories to search,
so I think -D will be hard to handle for multiple dirs.

Any suggestions appreciated.  I'm surprised I could find so
little on the internet on the topic of dlopen() and rpath.

BTW, my app is this.  I have an exec which accepts plugins.
The user would like to place the plugins in known directories
relative to the install dir for the exec and have the app
find the automatically without having to set LD_LIBRARY_PATH.
Some of these dirs include names with platform specific items
like redhat / suse and 32 / 64, etc as part of the dirname.

Thanks.

-William


> Yes, this is the expected behavior.
>
> DT_RPATH is considered obsolete in the current ELF spec.  DT_RUNPATH
> replaces it.  If DT_RUNPATH is present, DT_RPATH is ignored and only
> DT_RUNPATH is used, as per the spec.
>
> DT_RUNPATH does not apply in your example, though DT_RPATH does.
> DT_RUNPATH only affects the immediate dependencies of the object containing
> it, not other things like dlopen.  You can either use LD_LIBRARY_PATH, or
> if you wish to encode a path in your binary, you can do so by passing an
> complete file name including directory to dlopen.
>
>
> Thanks,
> Roland


Reply | Threaded
Open this post in threaded view
|

Re: dlopen/RPATH/RUNPATH

Roland McGrath
> This doesn't seem right to me.  If I go to the trouble of setting
> up an -rpath, why wouldn't you want dlopen() to respect it?

That is not what it's for.  You are talking about a global setting, and the
purpose of -rpath is for satisfying the dependencies of the thing you are
linking with -rpath.  If any DT_RUNPATH setting were to have this global
effect, it would pollute the search paths of the whole executable with the
private settings for one DSO to find its own dependencies.

> Regardless, if dlopen() is considered correct as is, how could
> I query the -rpath at runtime from within the application so that
> I can emulate the behavior I desire?  

I think what you really want to do is simply not rely on the search path
for your dlopen.  Pass dlopen a name like "$ORIGIN/../lib/libmine.so.1".
(Names containing /s are not subject to the search path.)