bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lt_dlopenadvise stops on encountering a non-library


From: Gary V. Vaughan
Subject: Re: lt_dlopenadvise stops on encountering a non-library
Date: Sun, 20 Apr 2008 16:40:38 -0400

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
`(_~)_




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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]