RTLD_NEXT plus LD_LIBRARY_PATH plus LD_PRELOAD doesn't work..?

["Matthias Urlichs" <smurf@noris.de>]

Hi,

the latest glibc doesn't always get LD_PRELOAD plus RTLD_NEXT right.

I don't know how difficult it'd be to do a small test case (I'll sit down
and do one if necessary). I noticed the problem trying to install the
latest development version of Perl with shared library support:

$ LD_LIBRARY_PATH=$(pwd) ldd ./miniperl
libperl.so => /usr/src/gnu/perl.exp/libperl.so (0x40012000)
libnsl.so.1 => /lib/libnsl.so.1 (0x400b9000)
libdb.so.3 => /lib/libdb.so.3 (0x400ce000)
libgdbm.so.1 => /lib/libgdbm.so.1 (0x40109000)
libdl.so.2 => /lib/libdl.so.2 (0x40110000)
libm.so.6 => /lib/libm.so.6 (0x40113000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4012e000)
libc.so.6 => /lib/libc.so.6 (0x4013c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4021c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ env LD_PRELOAD=/usr/src/misc/install-log/instlog.so LD_LIBRARY_PATH=$(pwd) \
./miniperl configpm tmp

instlog.so basically does this:
[...]
int __open(const char *a, int b, int c) {
    static int (*libc_open)(const char *,int,int) = NULL;

    libc_open = (typeof(libc_open))dlsym (RTLD_NEXT, "open");
    return (*libc_open)(a,b,c);
[...]
}
int open(const char *a, int b, int c) { return __open(a,b,c); }

... which (usually) works perfectly, but in this case it runs into an
endless loop because RTLD_NEXT mistakenly finds the local open() and not
the one from the next library.

Any ideas?

-- 
Matthias Urlichs
noris network GmbH