Bug 1287941 - dlopen can't open libm.so in 64 bits
dlopen can't open libm.so in 64 bits
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
23
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Carlos O'Donell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-02 23:35 EST by gastineau
Modified: 2015-12-03 10:02 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-03 10:02:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 18915 None None None Never
Linux Kernel 108821 None None None Never

  None (edit)
Description gastineau 2015-12-02 23:35:53 EST
Description of problem:

dlopen can't open the libm.so (/lib64/libm.so) in a 64-bits executable. 


Version-Release number of selected component (if applicable):
Fedora 23

How reproducible:


Steps to Reproduce:
1. install a fedora 23 and with gcc and  glibc-devel packages.
2. Copy the example from "man dlopen" and save it as a new file foo.c
3. gcc -m64 -rdynamic -o foo foo.c -ldl
4. ./foo

Actual results:
$./foo
/lib64/libm.so: invalid ELF header

Expected results:
$ ./foo
-0.416147


Additional info:
This problem desnot occur if the option "-m64" is replaced by "-m32" in order to create a 32-bit application.
For 32-bit application, /lib/libm.so is a link to ../../lib/libm.so.6.
For 64-bit application, /lib/libm.so is a GNU ld script.
The problem comes from that difference.
Comment 1 gastineau 2015-12-03 04:41:02 EST
I make a mistake in the additional info : this is "/lib64/libm.so" instead of "/lib/libm.so", for 64-bit application. 
/lib64/libm.so is a GNU ld script. I tink  that it should be a link
Comment 2 Greg Bailey 2015-12-03 09:06:33 EST
The "dl" component against which this was reported is a file transfer web application, and this problem report seems to be about glibc.  Reassigning.
Comment 3 Jakub Jelinek 2015-12-03 09:08:10 EST
glibc64 also is not what you are looking for.
Comment 4 Florian Weimer 2015-12-03 09:20:57 EST
This was already reported upstream.  After this comment

  https://sourceware.org/bugzilla/show_bug.cgi?id=18915#c6

it turned out that no glibc change was required.  glibc could provide something to support your needs, but we'd have to know what they are.

As I said upstream, you really should reference the full soname.
Comment 5 gastineau 2015-12-03 09:55:23 EST
Even if you assume that dlopen("libm.so", RTLD_LAZY); is now invalid, the documentation of dlopen provides an example with this library.
So you have to correct the example in "man dlopen". The glib developer must do it.
The examples, and the documentation, must match what developers are allowed to do. 
So the "man dolmen" example should use "LIBM_SO" from <gnu/lib-names.h>"  

If you do not provide an accurate documentation (scubas the small example provided in dlopen), this documentation will be useless for the developers and can be removed completely...
Comment 6 Florian Weimer 2015-12-03 10:02:14 EST
Let's continue the discussion on the upstream bug trackers.

Note You need to log in before you can comment on or make changes to this bug.