cross-compiling - 启用编译器优化时未找到 glibc

Question

我正在为 beaglebone black 设备交叉编译共享库 ( miniweb )。当我在没有优化的情况下编译时，没有任何问题。但是，如果我使用任何优化进行编译(即 -O3)，则在尝试运行我的程序时会得到以下信息:

./myprogram: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.15' not found (required by /usr/lib/libminiweb.so)

我的第一个问题，为什么启用优化会突然导致我的程序依赖于这个库？禁用优化时内容是否静态包含在库中？

如何确定我的交叉编译器正在使用的 c 库版本？我在两个系统上运行了以下命令ldd --version:

桌面:

$ ldd --version
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.6) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.

比格骨:

ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u1) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.

显然我拥有的库已经过时了，但是正如您所看到的，我的系统报告使用 eglibc 而不是 glibc？

我的交叉编译库如何依赖于glibc？也许在我的桌面上运行 ldd 并不能准确反射(reflect)我的交叉编译器使用的库？

如何找到我的交叉编译器正在使用哪个 C 库？

Answer 1

My first question, why would enabling optimizations suddenly cause my program to be dependent on this library?

您的程序依赖于libc.so.6，无论是否经过优化。您可以通过在目标系统上运行 ldd ./myprogram 来验证这一点。

发生的情况是，您的优化程序变得依赖于 libc.so.6 的更高版本，然后是您安装的版本。

假设头文件包含以下内容:

inline int foo() { return bar() + 1; }

进一步假设您的程序调用foo。如果不进行优化，foo 将不会被内联，并且您的程序将依赖于 foo。

通过优化，foo将内联，您的程序将不再依赖于foo，而是依赖于bar 相反。

如果在静态链接时，您链接到同时提供 foo 和 bar 的库 lifoobar.so，您的链接将会成功或没有优化。

如果在动态链接时(即运行时)使用不同版本的 libfoobar.so，则提供 foo 但不提供 bar，那么未优化的程序将正常运行，但优化的程序将失败，并找不到bar。

这就是发生在你身上的事情，只是你使用的是版本化符号some-libc-func@GLIBC_2.15，而不是bar，并且强制您的程序依赖于版本GLIBC_2.15，这是目标中缺少的内容。

Is content statically included in the library when optimizations are disabled?

没有。

How can I determine the c library version that my cross-compiler is using?

它使用libc-2.15.so或更高版本。您应该查看交叉编译器目录。

desktop: $ ldd --version

桌面上的内容完全不相关。重要的是你的交叉编译器正在使用什么。

How could my cross-compiled library be dependent on glibc?

您的交叉编译器提供 GLIBC 的自己的版本，并且您的交叉编译的二进制文件依赖那个 GLIBC。

换句话说，这里有 3 个不同版本的 GLIBC:

1. 桌面上的那个(无关)
2. 您的交叉编译器用来链接您的二进制文件
3. 您的目标 (beaglebone) 系统上的那个。

从错误消息中我们知道 (2) 至少是 GLIBC-2.15，并且我们知道 (3) 是 GLIBC-2.13(太旧了) )。

How can I find which c library my cross compiler is using?

在交叉编译器安装目录下查找它。

您还可以要求链接器为您打印它:

echo "int main() { return 0; }" | /path/to/cross-gcc -Wl,-t -xc -