Red Hat Bugzilla – Bug 1287941
dlopen can't open libm.so in 64 bits
Last modified: 2015-12-03 10:02:14 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.
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
The "dl" component against which this was reported is a file transfer web application, and this problem report seems to be about glibc. Reassigning.
glibc64 also is not what you are looking for.
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.
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...
Let's continue the discussion on the upstream bug trackers.