23
find | grep libc.so.6

reveals that it's in /lib/i386-linux-gnu/libc.so.6, but a script I was running expected it to be directly under /lib, so why isn't there at least a symlink?

Would I risk breaking anything if I put a symlink there?

Erik B
  • 567

3 Answers3

24

libc.so was 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 i386 and amd64 versions of libc at 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 libc6 package 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 dpkg pick?), defeating the entire point of the exercise.

Anything that hardcodes the path to libc.so must 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 multiarch tag.

Colin Watson
  • 6,340
  • 1
    Nice answer, learned something new today (again) :) – Lekensteyn May 05 '11 at 20:00
  • 1
    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 May 05 '11 at 20:30
  • @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 May 06 '11 at 07:41
  • @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. – Erik B May 06 '11 at 07:53
  • 3
    If you're never going to use 64-bit packages, I doubt there's any significant risk in adding a symlink, no. – Colin Watson May 06 '11 at 07:58
11

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 /etc/ld.so.conf, including /usr/lib and /lib by default. This file includes additional configuration files in /etc/ld.so.conf.d.

On my 64 bits system, libc.so.6 can be found in /lib/x86_64-linux-gnu/libc.so.6 because of the path defined in /etc/ld.so.conf.d/x86_64-linux-gnu.conf:

# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

To find out what library is loaded by a program, use ldd as in ldd /bin/bash:

    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 '^/'

-v causes a list of file + directories to be shown, -N prevents the cache (/etc/ld.so.cache) from being recreated.

Lekensteyn
  • 174,277
  • Putting the symlink would not break anything, but it wouldn't really do anything good either, right? – Erik B May 05 '11 at 17:33
  • @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. – Lekensteyn May 05 '11 at 17:38
  • 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? – crazy2be May 05 '11 at 23:33
  • @crazy2be: can you post the output of ldconfig -v -N | grep '^/' ? – Lekensteyn May 06 '11 at 07:42
  • @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 May 07 '11 at 02:57
  • @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. – Lekensteyn May 07 '11 at 08:01
5

Just add symlink to the libc.so.6 file as following:

sudo ln -s /lib/i386-linux-gnu/libc.so.6 /lib/libc.so.6

The same goes for other missing files still on the system, in my case Matlab was missing the file, the problem is gone now.

N.N.
  • 18,219
Robert Hughes
  • 51