Bug 131097 - no /lib/libc.so is present
Summary: no /lib/libc.so is present
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 2
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-27 14:55 UTC by Sam Steingold
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-30 06:20:40 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Sam Steingold 2004-08-27 14:55:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040614 Firefox/0.8

Description of problem:
dlopen("/lib/libc.so") does not work:
"/lib/libc.so: cannot open shared object file: No such file or directory"
This is because there is no "/lib/libc.so", only "/lib/libc.so.6".
adding a symbolic link solves the problem.
note that there are "/usr/lib/libc.so" and "/usr/lib/libc.a",
but they do not work:
"/usr/lib/libc.a: invalid ELF header"
"/usr/lib/libc.so: invalid ELF header"

dlopen("/lib/libc.so") works on other UNIXes (solaris, cygwin).
it would be nice if it worked on linux too.

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

How reproducible:

Steps to Reproduce:

Actual Results:  perror("/lib/libc.so"):
"/lib/libc.so: cannot open shared object file: No such file or directory"

Expected Results:  library is opened.

Additional info:
 this is probably relevant to all platforms, not just athlon.

Comment 1 Bruno Haible 2004-08-27 20:38:16 UTC
There is absolutely no need to have a /lib/libc.so file. You need to 
understand the roles of these files: 
  - *.so.X.Y files are used by the dynamic linker (i.e. at program startup 
    and at dlopen() time). The version number here is mandatory because 
    it must be avoided to link dynamically against a shared library with 
    an incompatible ABI, compared to the one that was intended. 
  - *.so files are used by the linker (ld). These can be symlinks to 
    *.so.X.Y files, or linker scripts (such as /usr/lib/libc.so). 
So the argument of a dlopen() call should be a "*.so.X.Y" string. 
Also, dlopen("/lib/libc.so") is not portable because it will not work on 
GNU/Hurd, where /usr == / and /lib/libc.so is a linker script. 

Comment 2 Sam Steingold 2004-08-27 20:48:42 UTC
some functions, like malloc() and free(), are ABI-independent.
for the sake of such functions, a "/lib/libc.so" should be provided.
every unix has it. if hurd doesn't, it's not a unix.

Comment 3 Jakub Jelinek 2004-08-30 06:20:40 UTC
Even dlopening /lib/libc.so.6 is not going to work and /lib/libc.so
is definitely not going to be added.  Portable programs must never do
anything like that.  Furthermore, libfoo.so files are not meant for dynamic linking.
If you are writing malloc/free wrappers and want to use the original
malloc/free, just use dlsym (RTLD_NEXT, "malloc") etc., or you can use
dl_iterate_phdr API to query which libraries are loaded and search for
libc among them, though RTLD_NEXT is definitely preferred, as then
you can chain multiple wrapper libs together.

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