【发布时间】:2020-10-25 04:24:48
【问题描述】:
此问题与Why does pclose return prematurely? 有关。 我想知道libc 的哪个版本用于交叉编译的可执行文件。 存在如下所述的限制,导致Check glibc version for a particular gcc compiler 的答案不适用。
-
检查
libc版本的一种建议方法是使用gnu/libc-version.h中声明的gnu_get_libc_version()函数。我的跨工具链不包括libc-version.h。 -
另一个建议的解决方案是使用
-print-file-namegcc选项。链接问题中的这个答案完全不适合我:
$ /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc -print-file-name=libc.so
libc.so
$
$ /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc -print-file-name=foo.bar
foo.bar
$ # I really do not have a foo.bar file in existence
- 另一个建议的解决方案是只做
ldd --version。我的目标平台没有ldd:
$ ldd
sh: can't execute 'ldd': No such file or directory
- 另一个建议的解决方案是查看
__GLIBC__和__GLIBC_MINOR__——但这些似乎也来自libc-version.h,如上所述,它们在我的跨工具链中不存在。
我的跨工具链似乎只提供libc.a,而不提供libc.so。
我尝试运行 libc.a 到 /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-nm 和 strings grepping(不区分大小写)“版本”和“libc”,但没有找到任何看起来像识别版本的东西。
我最后尝试的是strings /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc | grep GLIBC,它给了我:
GLIBC_2.3
GLIBC_2.2
GLIBC_2.1
GLIBC_2.0
EGLIBC configuration specifier, serves multilib purposes.
但该解决方案并没有得到很高的评价,而且它还有一条评论表明它并没有真正为您提供版本。 我不太了解这个答案或它的回复评论,所以我不知道如何理解它的有效性。
问题:鉴于以上所有情况,是否有任何确定的方法可以确定用于此跨平台交叉编译的 libc 版本?
【问题讨论】:
-
strings很可能只是告诉您编译器可执行文件本身与(主机)glibc 链接。这不会告诉你它生成的可执行文件的作用。 -
听起来你的目标平台可能根本不使用 glibc,但可能是一些完全不相关的 C 库,所以 glibc 的东西可能没有任何用处。 C 库的每个实现都可以自行决定如何报告其版本编号(如果有的话);据我所知,没有标准接口。因此,您需要找出您安装的 C 库并阅读其文档。
-
哇,感谢您为研究这个问题所做的努力。对另一个问题的评论表明您可能正在处理 uclibc。您可以尝试this answer 并检查它是否为您提供了正确的版本吗?
-
@NateEldredge - 编译器/工具链是否完全独立于
libc?我认为因为编译器是gcc(的交叉编译风格),这意味着它是gnu工具链,因此还包括gnulibc...? -
@StoneThrow:不,编译器和 C 库通常彼此不可知。只要他们都遵守正确的 ABI,任何组合都应该有效。
标签: c cross-compiling libc