Question

我在我的Linux Mint 14 Nadia中安装了Matlab（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位版本。

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

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

这不是库，而是链接器脚本文件，它引用上面的符号链接。

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

首先，无论安装了libc版本，链接器都将始终搜索libc.so，因为编译器驱动程序将始终将-lc选项传递给链接器。名称libc保持不变，并表示最新版本的库。

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

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

最后，名称libc-2.15.so引用了libc版本，当您安装新的libc软件包时，名称将更改为libc-2.16.so。如果它与先前版本二进制兼容，libc.so.6链接将保持这种方式命名，现有的可执行文件将继续工作。

Answer 2

要找到要使用的那个，您必须首先找到ld（链接器）用于查找库的顺序，如下所示：

ld --verbose | grep SEARCH

对我而言，它给了我这个输出：

SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64"); SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");

这意味着在我的计算机上，ld按顺序查看这些目录：

的/ usr / x86_64的未知-Linux的GNU / lib64下
的/ usr / x86_64的未知-Linux的GNU / lib中
/ usr / lib中
的/ usr /本地/ lib中

所以如果libc在/ usr / x86_64-unknown-linux-gnu / lib64中，并且libc也在/ usr / lib中，那么它将使用/ usr / x86_64-unknown-linux-gnu / lib64版本，因为它被列在第一位。

Answer 3

您创建的符号链接对GCC没有任何影响。只有在使用-m32 GCC标志进行编译时才使用32位版本。 GCC不会尝试生成32位二进制文件，除非您明确告诉它（通过使用该标志。）

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

3 个答案: