On Wed, Dec 20, 2000 at 01:54:04PM -0600, Albert Chin-A-Young 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.
>
> BTW, I posted the same message to comp.unix.solaris and it turns out
> there is a solution. In my code below, I dlopen libz.so and then
> libpng.so. This fails. libpng.so has a hard-coded dependency on
> libz.so.2. So, if I dlopen libz.so.2 and then libpng.so, everything
> works! Now, I don't think libtool embeds enough information in the
> *.la files to figure this out.
>
> My libz.la file looks like:
> dlname=''
> library_names='libz.so.2.0.0 libz.so.2 libz.so'
> old_library='libz.a'
> dependency_libs=''
>
> and libpng.la looks like:
> dlname=''
> library_names='libpng.so.1.0.0 libpng.so.1 libpng.so'
> old_library='libpng.a'
> dependency_libs=' -L/opt/TWWfsw/zlib11/lib /opt/TWWfsw/zlib11/lib/libz.la -lm'
>
> So, how can we make lt_dlopen load libz.so.2 when we load libpng.la?
>
> Ok, why is dlname empty? Turns out that if:
> dlname='libz.so.2'
> then lt_dlopen("libpng.la") will work!
Ok, '-module' fills dlname.
--
albert chin ([EMAIL PROTECTED])
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
