lt_dlopenadvise stops on encountering a non-library

[Anton Ertl]

      host-triplet:     x86_64-unknown-linux-gnu
      shell:            /bin/sh
      compiler:         gcc
      compiler flags:           -g -O2
      linker:           /usr/bin/ld -m elf_x86_64 (gnu? yes)
      libtool:          (GNU libtool) 2.2.2
      automake:         automake (GNU automake) 1.9.6
      autoconf:         autoconf (GNU Autoconf) 2.61

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.

- anton