Re: dlopen on Solaris compared with IRIX/Tru64

[Tom Kacvinsky]

I am not so sure about this.  From the man page for dlopen():

     If other objects were link-edited with pathname  when  path-
     name  was  built,  that is, the pathname has dependencies on
     other objects, those objects will automatically be loaded by
     dlopen(). The directory search path used to find both  path-
     name and the other needed objects may be affected by setting
     the  environment variable LD_LIBRARY_PATH, which is analyzed
     once at process startup, and from a runpath  setting  within
     the object from which the call to dlopen() originated. These
     search rules will only be applied to path names that do  not
     contain  an  embedded   '/'.  Objects whose names resolve to
     the same absolute or relative path name may  be  opened  any
     number  of times using  dlopen(); however, the object refer-
     enced will only be loaded once into the address space of the
     current process.

The key point is the line:

    ... and from a runpath setting within the object from which
    the call to dlopen() originated.

That is, the RPATH used is the RPATH from the binary which invokes
dlopen, and the RPATHs in the shared object dependencies is not
used at all.  Unless the man page is in error.

Tom

On Wed, 20 Dec 2000, Bjoern Fischer wrote:

> On Wed, Dec 20, 2000 at 02:01:17PM -0500, Tom Kacvinsky wrote:
> > Huh?  My experience (on Solaris) has been that if foo.so has an embedded 
> > RPATH
> > and the application bar uses foo.so and also has a RPATH, then the binary's
> > RPATH is used for shared lib lookups.  If the RPATH of the binary does not
> > include the paths in the shared lib's RPATH, then the shared lib's 
> > dependencies
> > are not met. :( Or maybe I am consfusing myself.  Perhaps this is Tru64 
> > UNIX's
> > behavior.
>
> Yup, this sounds like Tru64 or pre-6.5 IRIX. Solaris (as *BSD and Linux,
> I think, too) uses RPATH of ojbect A only for looking after the
> dependencies of object A. This is for run-time linking as well as
> for dlopen(), which is unlike ELF run-time linking poorly founded on
> existing standards.
>
>   Bjoern
>
>