Re: lt_dlopenadvise stops on encountering a non-library

[Gary V. Vaughan]

Hi Anton,

On 30 Apr 2008, at 15:07, Anton Ertl wrote:
> 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.

Thanks for chasing this.  Again, I'm not sure why you would need to
dlopen libc, since it is already loaded by the linker when an  
application
comes up, but anyway...

> 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.

There's no way to get the soname portably without already having the
full path of the library.  Potentially, we might have been able to
follow softlinks, or even to extract the full soname from the generic
.so suffix library... except that the linker script you are tripping  
over
would break those ideas too :-(

> 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).

I'll look into that when I have more time, but in the meanwhile, if
you already know you are goinng to open using a full pathname, you
can just use

    lt_dlopen("libc.so.6")

or, considering how non-portable that is:

    dlopen("/lib/libc.so.6")

will do just as well.

> 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.

lt_dlopenext is supposed to first try the name as passed in the search
path, and then try both .la and the host suffix (".so" in your case).   
It
certainly isn't tied to .la files... unless you have uncovered a bug  
here.

> 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.


It's certainly a lot more portable than dlopen("/lib/libc.so.6")! :-)

Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_

PGP.sig
Description: This is a digitally signed message part