Bug 346095 – dlopen() fails because unversionned shared library not available in /lib{,64} and only a linker script is in /usr/lib{,64}

• Product: Gentoo Linux
• Status: VERIFIED DUPLICATE

[Description Laurent Parenteau 2010-11-19 16:32:43 UTC]

This issue has been reported late in https://bugs.gentoo.org/show_bug.cgi?id=4411, but it is a different issue then the original problem, so I'm opening a new one for it.

From https://bugs.gentoo.org/show_bug.cgi?id=4411#c39 :
Linker scripts do break dlopen().  If you try and dlopen("libpcre.so", _) then it will fail.  The problem is that while /lib{,64} is searched before /usr/lib{,64}, there is no libpcre.so in /lib{,64}, just libpcre.so.0{,.0.1}.  So the first file the dynamic linker finds when you use dlopen() is the linker script in /usr/lib{,64}, and since that isn't a valid ELF file, dlopen() fails.  
If we're going to keep with these linker scripts in /usr/lib, can we at least
consider having symlinks in /lib for libpcre, etc. like there are for most
other libraries?  Otherwise we'll keep having problems with interpreted
languages that need to open the libs at runtime rather than using the static
linker (note that Template Haskell in GHC uses ghci; thus even building
packages that use Template Haskell and require linking to libpcre - for example
dev-haskell/highlighting-kate in the Haskell overlay - fail to work).

I've encountered the same problem with /usr/lib64/libz.so, which is a linker script, and there's no /lib64/libz.so symlink, only /lib64/libz.so.1.

Reproducible: Always

Steps to Reproduce:
See https://bugs.gentoo.org/show_bug.cgi?id=4411#c40 for a sample program.

Actual Results:  
dlopen() fails because /usr/lib(64)/libxxx.so isn't a shared library.

Expected Results:  
dlopen() should work "out of the box", even with unversionned shared libraries.

If we're going to keep with these linker scripts in /usr/lib{64}, can we at least
consider having symlinks in /lib{64} for libpcre, etc. like there are for most
other libraries?  Otherwise we'll keep having problems with interpreted
languages that need to open the libs at runtime rather than using the static
linker (note that Template Haskell in GHC uses ghci; thus even building
packages that use Template Haskell and require linking to libpcre - for example
dev-haskell/highlighting-kate in the Haskell overlay - fail to work).

[Comment 1 SpanKY 2010-11-19 22:41:00 UTC]

your code is wrong

*** This bug has been marked as a duplicate of bug 290974 ***