Re: lt_dlopenadvise stops on encountering a non-library

[Anton Ertl]

Gary V. Vaughan wrote:
> As I explained in my last message, I don't think that  
> lt_dlopenext("libc")
> is the right thing to do.  Unfortunately, even though my platform has a
> real shared library at /usr/lib/libc.dylib, it can't be opened with
> lt_dlopen.
> 
> What happens if you try to use libdl to dlopen("/lib/libc.so")?  If you
> still get the error, then libtool can't help.  If dlopen works, then it
> is a libltdl bug for lt_dlopen("/lib/libc.so") to fail.

I have made a bug report on this
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477188>, and it was
not considered a bug, because "libc.so" is not the correct SONAME for
libc.  Instead, one should use "libc.so.6".  The libc.so file is there
for use by ld according to an email exchange I had after the bug
report was closed.

So maybe lt_dlopenext()/lt_dladvise_ext() should cause ".so.6" to be
appended in that case.  I guess that will not be easy to implement,
though.

Anyway, the bad thing about the current implementation is that when I
do lt_dlopenext("libc.so.6"), it tries to open "libc.so.6.so" (which
fails), and does not try "libc.so.6" (which would succeed).

BTW, if the ...ext() feature only works for ".la" files, that's very
little functionality.  I guess that an ...ext() feature that's
unreliable for non-.la files can still be useful for some
applications.

For (the main usage in) my application I found a completely different
solution: I build some files with wrapper functions for calling these
libraries anyway.  Now, instead of dlopening the libraries explicitly,
I just make them dependent libraries of my wrapper libraries by
passing "-l<lib>" parts to the "libtool -mode=link" invocations that
build the wrapper libraries.  I hope that that's portable.

- anton