我正在为beaglebone黑色设备交叉编译共享库（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.
beaglebone：
ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u1) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
显然我的图书馆已经过时，但您可以使用eglibc代替glibc查看我的系统报告？
我的交叉编译库如何依赖于glibc？也许在我的桌面上运行ldd并不能准确反映我的交叉编译器使用的库？
如何找到交叉编译器正在使用的c库？
答案 0 :(得分：2)
我的第一个问题，为什么启用优化突然导致我的程序依赖于这个库？
您的程序 依赖于libc.so.6，有无优化。您可以通过在目标系统上运行ldd ./myprogram来验证这一点。
发生的事情是，您的优化程序依赖于libc.so.6的更高版本，然后是您已安装的
假设头文件包含以下内容：
inline int foo() { return bar() + 1; }
进一步假设您的程序调用{{1}}。如果没有优化，foo将不内联，您的程序将取决于foo。
通过优化，{<1}} 将内联，您的程序将不再依赖foo，而是取决于foo。
如果在静态链接时，您链接到同时提供foo和bar的库lifoobar.so，则无论是否进行优化，您的链接都会成功。
如果在动态链接时（即在运行时）使用foo的不同版本，提供bar但不提供libfoobar.so的版本，那么未经优化的程序将运行正常，但优化后的程序将失败且找不到foo。
这就是您发生的事情，而不是bar您正在使用版本化符号bar，而 强制您的程序依赖于版本bar，这是目标中缺少的。
禁用优化时，内容是否静态包含在库中？
没有
如何确定交叉编译器正在使用的c库版本？
使用some-libc-func@GLIBC_2.15或更高版本。您应该查看交叉编译器目录。
桌面：
GLIBC_2.15
桌面上的内容完全不相关。重要的是您的交叉编译器正在使用的内容。
我的交叉编译库如何依赖于glibc？
您的交叉编译器提供了其自己的GLIBC版本，您的交叉编译二进制文件依赖于 GLIBC。
换句话说，这里有3个不同版本的GLIBC：
我们知道（2）错误消息中至少libc-2.15.so，并且我们知道（3）是$ ldd --version（这太旧了）。
如何找到交叉编译器正在使用的c库？
在交叉编译器安装目录下查找。
您也可以要求链接器为您打印：
GLIBC-2.15