问题描述
find | grep libc.so.6
显示它位于 /lib/i386-linux-gnu/libc.so.6 中，但我运行的脚本期望它直接位于 /lib 下，那么为什么至少没有一个符号链接呢？
如果我在那里放置符号链接，我会冒破坏任何东西的风险吗？
最佳方案
libc.so 作为 Ubuntu 11.04 中 multiarch 工作的一部分被移动。那里不能有符号链接的原因是，多架构的目的是可以同时安装 libc 的 i386 和 amd64 版本，以便您可以更轻松地在 64 位上运行 32 位二进制文件位系统，反之亦然(以及其他类似情况)。如果 libc6 包包含指向新位置的符号链接，则不同体系结构的该包的版本将无法同时安装(dpkg 将选择哪个版本的符号链接？)，从而破坏了整个练习的要点。
从 Ubuntu 11.04 开始，任何硬编码 libc.so 路径的内容都必须更新才能正常工作。如果您正在谈论的脚本是 Ubuntu 的一部分，请报告其错误并添加 multiarch 标签。
次佳方案
动态库由内核加载，路径不是硬编码在程序中。程序只是说“我需要 libc.so.6”。然后系统会搜索 /etc/ld.so.conf 中定义的库路径，默认包括 /usr/lib 和 /lib 。该文件包括 /etc/ld.so.conf.d 中的附加配置文件。
在我的 64 位系统上，由于 /etc/ld.so.conf.d/x86_64-linux-gnu.conf 中定义的路径，可以在 /lib/x86_64-linux-gnu/libc.so.6 中找到 libc.so.6 ：
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
要找出程序加载的库，请使用 ldd，如 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)
放置符号链接不会破坏任何东西。
要获取搜索到的目录列表，请运行：
ldconfig -v -N | grep '^/'
-v 导致显示文件+目录的列表，-N 防止重新创建缓存( /etc/ld.so.cache )。
第三种方案
只需将符号链接添加到 libc.so.6 文件，如下所示：
sudo ln -s /lib/i386-linux-gnu/libc.so.6 /lib/libc.so.6
对于系统上仍然存在的其他丢失文件也是如此，在我的例子中，Matlab 丢失了该文件，问题现在已经消失了。