Re: dlopen on Solaris compared with IRIX/Tru64

[Tom Kacvinsky]

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.

Anyway, I guess I am talking about run-time linking, and not use of dlopen.
Or is the bahvior the same?

Tom

On Wed, 20 Dec 2000, Bjoern Fischer wrote:

> Hello Albert,
>
> > dependent on nothing:
> >   $ ldd libpng.so
> >   libz.so.2 =>     (file not found)
>
> This is your problem. Your libpng.so is not self-contained.
> The run-time linker is not able to resolve all dependencies
> of your libpng.so. You may set LD_LIBRARY_PATH, but you
> definetly want to fix your libpng.so to contain an DT_RPATH
> for libz.so.
>
> > This program works just fine on IRIX 6.5 and Compaq Tru64 UNIX 5.0.
> > The failure above is on Solaris 2.5.1-8/SPARC.
>
> That's irony! The Platforms Tru64 and IRIX are more or less broken
> with respect to run-time linking resp. dlopen():
>
> The creator of libpng.so really knows what other libraries png
> depends on and where to find them. This knowledge should be
> incorprated into libpng.so, so the run-time linker will be able
> to find all libs and resolve all symbols. Solaris' run-time
> linker only uses the RPATH found in libpng.so to find libs,
> that png depends on. IRIX and True64 use a globalized RPATH
> in the executable binary for all library searches, which is
> wrong.
>
>   Bjoern
>
>