Why is /lib/libc.so.6 missing?
libc.sowas moved as part of the multiarch work in Ubuntu 11.04. The reason that there can't be a symlink there is that the purpose of multiarch is to make it possible to install both the
libcat the same time so that you can run 32-bit binaries more easily on 64-bit systems and vice versa (and other similar situations). If the
libc6package contained a symlink to the new location, then the versions of that package for different architectures wouldn't both be installable at the same time (which version of the symlink would
dpkgpick?), defeating the entire point of the exercise.
Anything that hardcodes the path to
libc.somust be updated to work properly from Ubuntu 11.04 onwards. If the script you're talking about is part of Ubuntu, please report a bug on it and add the
The processor I'm using doesn't even support 64 bit instructions. Would you say there's any risk associated with manually adding a symlink? Not sure I need to do that, but if. Anyway, this seems to be the correct answer. Thanks.
@Erik B: what? Are you telling me you're trying to use a 64 app on a 32 bits processor? That's definitely **not** going to work. 32 bits apps work fine on a 64 bits processor, but not vice versa.
@Lekensteyn that's definitely not what I'm saying. What I'm saying is that I have no use for the 64 bit library. So on my particular system there's not going to be any confusion about whether `/lib/libc.so.6` is the 32 or 64 bit library.
Dynamic libraries are loaded by the kernel, the paths are not hardcoded in a program. A program just says "I need libc.so.6". The system then searches in library paths as defined in
/libby default. This file includes additional configuration files in
On my 64 bits system,
libc.so.6can be found in
/lib/x86_64-linux-gnu/libc.so.6because of the path defined in
# Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu
To find out what library is loaded by a program, use
linux-vdso.so.1 => (0x00007ffff1dff000) libncurses.so.5 => /lib/libncurses.so.5 (0x00007f9d8b3b8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9d8b1b4000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d8ae1f000) /lib64/ld-linux-x86-64.so.2 (0x00007f9d8b61c000)
Putting the symlink would not break anything.
To get a list of directories that are searched, run:
ldconfig -v -N | grep '^/'
-vcauses a list of file + directories to be shown,
-Nprevents the cache (
/etc/ld.so.cache) from being recreated.
Putting the symlink would not break anything, but it wouldn't really do anything good either, right?
@Erik B: what program / script are you referring to? I can understand that a script gets confused because the path is hardcoded. But a program does not have to know the path.
Is that how it works? I seem to have issues sometimes where programs cannot find libraries installed in `/usr/local/lib`, but they work fine if I make a symlink from `/usr/lib`. What causes this behavior?
@Lekensteyn: Sure: http://pastebin.com/dtfnw2Tv. It's happened with some programs on almost any system i've used, however, so I assumed it was not related to system configuration.
@crazy2be: what's `/usr/local/lib/libstdc++.so.6.0.14-gdb.py` doing there? Only shared libraries (`*.so`) should be placed there and their symlinks with version information (`*.so.x`, `*.so.x.y` and `*.so.x.y.z`). I think that file is an installer, not actually a shared library.