> 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
[...]
> ... 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
eh, the dlopened object's RPATH?
> used at all. Unless the man page is in error.
The man page is wrong here. The RPATH of the dlopened object
*is* searched. You can prove it yourself with this tiny (~1K)
example, that I wrote as an indicator for run-time linkers,
that do *not* search the dlopened object RPATH:
http://www.TechFak.Uni-Bielefeld.DE/~bfischer/dlopen-bug.tar.gz
Bjoern Fischer
--
-----BEGIN GEEK CODE BLOCK-----
GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+
K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+
------END GEEK CODE BLOCK------
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
