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): glibc-2.3.3-27 How reproducible: Always Steps to Reproduce: 1.dlopen("/lib/libc.so") 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.
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.
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.
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.