Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 346095 - dlopen() fails because unversionned shared library not available in /lib{,64} and only a linker script is in /usr/lib{,64}
Summary: dlopen() fails because unversionned shared library not available in /lib{,64}...
Status: VERIFIED DUPLICATE of bug 290974
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Linux bug wranglers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-19 16:32 UTC by Laurent Parenteau
Modified: 2010-11-20 00:57 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 gentoo-dev 2010-11-19 22:41:00 UTC
your code is wrong

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