Bug 1287941

Summary:	dlopen can't open libm.so in 64 bits
Product:	[Fedora] Fedora	Reporter:	gastineau <amgastineau>
Component:	glibc	Assignee:	Carlos O'Donell <codonell>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	23	CC:	arjun.is, codonell, fweimer, gbailey, herrold, jakub, law, mfabian, pfrankli, schwab, siddhesh
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-03 15:02:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description gastineau 2015-12-03 04:35:53 UTC

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 09:41:02 UTC

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 14:06:33 UTC

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 14:08:10 UTC

glibc64 also is not what you are looking for.

Comment 4 Florian Weimer 2015-12-03 14:20:57 UTC

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 14:55:23 UTC

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 15:02:14 UTC

Let's continue the discussion on the upstream bug trackers.