这个问题与为什么pclose会提前返回有关。我想找出交叉编译可执行文件所使用的
另一个提出的解决方案是只执行
另一个提议的解决方案是查看
我的交叉工具链似乎只提供
我尝试通过
我最后尝试的方法是
libc
版本。下面介绍的限制使得检查特定gcc编译器的glibc版本的答案不适用。
一个提议的方法是使用在
gnu/libc-version.h
中声明的gnu_get_libc_version()
函数来检查libc
版本。我的交叉工具链没有包含libc-version.h
。另一个解决方案是使用
-print-file-name
gcc
选项。链接问题中的答案对我根本没有用:
$ /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
。我尝试通过
/path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-nm
和strings
对libc.a
进行搜索(忽略大小写)以查找“version”和“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进行了链接。这并不能告诉你它所生成的可执行文件的作用。 - Nate Eldredge/path/to/toolchains/ARM-cortex-m3-4.4/sysroot/include/stdlib.h
,上面写着版权为“1991-2007, 2009”。听起来这种方法 - 即浏览头文件 - 在这种情况下是最好的途径,谢谢你。 - StoneThrow