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

Reply via email to