If a subdirectory of an entry in LD_LIBRARY_PATH is named the same as a library that ld-linux.so is trying to locate, it'll get confused and open the directory as if it were the library itself. The loader doesn't like this much as it'll try to find and ELF header in the directory entry (which it obviously won't find) and it'll error out. In the glibc source elf/dl-load.c, the open_path function is looping over entries in LD_LIBRARY_PATH trying to find various libraries. It eventually calls open_verify to try an actually open the library. open_verify will issue and __open() on the specified path. If this path (which is named like a library) is a directory, the __open() will succeed. If the open succeeds, open_verify tries to verify that it's an ELF file (which it's not). It seems like a stat() to check if what you're opening is actually a file would be a good fix. (I'd supply a patch, but I'm not a glibc hacker. :-) Reproducible: Always Steps to Reproduce: 1. mkdir -p /tmp/lib/libc.so.6 2. export LD_LIBRARY_PATH=/tmp/lib 3. Run anything that's dynamically linked Actual Results: $ export LD_LIBRARY_PATH=/tmp/lib $ ls ls: error while loading shared libraries: /tmp/lib/libc.so.6: cannot read file data: Error 21 $ /bin/sh /bin/sh: error while loading shared libraries: /tmp/lib/libc.so.6: cannot read file data: Error 21 etc... Expected Results: ld-linux.so shouldn't try to open directories and then try to treat them like ELF files. This is all relevant because revdep-rebuild uses LD_LIBRARY_PATH when searching for broken dependancies. This is how I found this bug. I have vmware-workstation installed and it has a library installed as /opt/vmware/lib/lib/libgdk_pixbuf.so.2/libgdk_pixbuf.so.2. So revdep-rebuild will add /opt/vmware/lib/lib to the LD_LIBRARY_PATH. Then when trying to find the library libgdk_pixbuf.so.2, it'll fail (because of this bug) and (in my case) not find a broken dependancy. Hmm... I guess this is also a bug in revdep-rebuild (it probably shouldn't silently fail when it gets an error from ldd).
Confirmed that this is still an issue. Can someone push this upstream or come up with a patch? :)
Created attachment 75481 [details, diff] glibc-dirs-are-not-elfs.patch this should fix it
i'm pretty sure this is intended behavior but i sent the patch upstream anyways
yeah, upstream says this is expected behavior, so i wont include the patch in our Gentoo ebuild
(In reply to comment #4) > yeah, upstream says this is expected behavior, so i wont include the patch in > our Gentoo ebuild Ok, fair enough (thanks for looking into it). Out of curiosity, why does upstream think that this behavior is good?
they consider it something that shouldnt be wrong ... here's a comment from the code itself: /* Open a file and verify it is an ELF file for this architecture. We ignore only ELF files for other architectures. Non-ELF files and ELF files with different header information cause fatal errors since this could mean there is something wrong in the installation and the user might want to know about this. */ they dont think of dirs as a special non-elf case
