gcc -/lib/i386-linux-gnu/libc.so.6、/lib/x86_64-linux-gnu/libc.so.6 和/usr/lib/x86_64-linux-gnu/libc.so 有什么区别？

Question

我在我的 Linux Mint 14 Nadia 中安装了 Matlab(a uname -a 显示:Linux Ideapad-Z570 3.5.0-17-generic#28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux)和从命令行调用它时，我会得到:“/lib64/libc.so not found”。

我通过在/lib64 中创建一个链接来遵循 mathworks 的帮助:

ln -s /lib/x86_64-linux-gnu/libc.so.6 .

这解决了这个问题。

现在，如果我对这个库进行定位，我会得到:

locate "libc.so"
/lib/i386-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6
/usr/lib/x86_64-linux-gnu/libc.so

我将在这台计算机上使用 gcc 进行编译，我想要完整的 64 位编译。拥有所有这些不同的 libc.so 库究竟意味着什么？ gnu 编译器将使用哪一个？我需要用 gcc 做任何不同的事情来编译 64 位吗？

我也很想尽可能优化我的新 i7 内核!!!

Answer 1

/lib/i386-linux-gnu/libc.so.6

这是该库的 32 位版本。

/lib/x86_64-linux-gnu/libc.so.6

这是该库的 64 位版本。

两者通常都是指向实际库文件的符号链接(symbolic link)，通常会根据 glibc 版本号命名，例如 libc-2.15.so

/usr/lib/x86_64-linux-gnu/libc.so

这不是一个库，而是一个链接器脚本文件，它引用了上述符号链接(symbolic link)。

为什么我们需要所有这些:

首先，无论安装的 libc 版本如何，链接器都会一直搜索 libc.so ，因为编译器驱动程序总是将 -lc 传递给链接器选项。姓名 libc保持不变并表示库的最新版本。

符号链接(symbolic link) libc.so.6以库的 soname 命名，或多或少对应于库的 ABI 版本。可执行文件，链接到 libc.so实际上包含对 libc.so.6 的运行时依赖项.

如果我们想象有一天会发布一个严重不兼容 ABI 的 libc，它的 soname 可以命名为 libc.so.7 ，例如，此版本可以与旧的 libc.so.6 共存。版本，因此与一个或另一个链接的可执行文件可以在同一系统中共存，

最后，名称 libc-2.15.so指的是libc版本，当你安装一个新的libc包时，名称会变成 libc-2.16.so .如果它与以前的版本二进制兼容， libc.so.6链接将保持这种命名方式，现有的可执行文件将继续工作。