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
>
>
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
