Re: lt_dlopenadvise stops on encountering a non-library

[Gary V. Vaughan]

Hi Anton,

Thanks for the report.

On 18 Apr 2008, at 16:10, Anton Ertl wrote:
> Now that my variant of lt_dlopenext() seems to work as intended, I
> played around with it and found that it does not like to open "libc"
> or "libc.so", but "libc-2.3.6" works fine.  With strace -e trace=file,
> I see the following when trying to open "libc":
>
> open("/lib/libc.la", O_RDONLY)          = -1 ENOENT (No such file or  
> directory)
> open("/usr/lib/libc.la", O_RDONLY)      = -1 ENOENT (No such file or  
> directory)
> open("/usr/local/lib/libc.la", O_RDONLY) = -1 ENOENT (No such file  
> or directory)
> open("/usr/local/lib64/libc.la", O_RDONLY) = -1 ENOENT (No such file  
> or directory)
> open("/usr/local/lib32/libc.la", O_RDONLY) = -1 ENOENT (No such file  
> or directory)
> open("/lib/x86_64-linux-gnu/libc.la", O_RDONLY) = -1 ENOENT (No such  
> file or directory)
> open("/usr/lib/x86_64-linux-gnu/libc.la", O_RDONLY) = -1 ENOENT (No  
> such file or directory)
> open("libc.la", O_RDONLY)               = -1 ENOENT (No such file or  
> directory)
> access("/lib/libc.so", R_OK)            = -1 ENOENT (No such file or  
> directory)
> access("/usr/lib/libc.so", R_OK)        = 0
> open("/usr/lib/libc.so", O_RDONLY)      = 4
>
> But the lt_dlopenadvice then returns 0.  I looked at the
> /usr/lib/libc.so file, and found that it contains the following:
>
> -----------------------------------------
> /* GNU ld script
>   Use the shared library, but some functions are only in
>   the static library, so try that secondarily.  */
> OUTPUT_FORMAT(elf64-x86-64)
> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld- 
> linux-x86-64.so.2 ) )
> -----------------------------------------
>
> This is apparently not understood as a (reference to a) shared library
> by lt_dlopenadvise (or whatever it calls), but it does not try to
> search further, either (Would that help? Probably not).
>
> I am not sure whose bug this is, but since I am seeing it through
> libltdl, I report it to you first.  Sorry if this is wrong.


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.

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