Bug 131097 - no /lib/libc.so is present
no /lib/libc.so is present
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-08-27 10:55 EDT by Sam Steingold
Modified: 2007-11-30 17:10 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Sam Steingold 2004-08-27 10:55:42 EDT
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 16:38:16 EDT
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 16:48:42 EDT
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 02:20:40 EDT
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.