OK, I believe you know. :) I either read the dlopen man page
incorrectly, or the dlopen mane page is incorrect.
Thanks...
Tom
On Thu, 21 Dec 2000, Bjoern Fischer wrote:
> > 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
>
>
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool