This question is related to Why does pclose return prematurely?. I'd like to find out what version of libc is used for a cross-compiled executable. There are limitations, described below, that make the answers at Check glibc version for a particular gcc compiler not apply.
One proposed way to check the
libcversion is to use thegnu_get_libc_version()function declared ingnu/libc-version.h. My cross-toolchain does not includelibc-version.h.Another proposed solution is to use the
-print-file-namegccoption. This answer in the linked question just flat-out didn't work for me:
$ /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
- Another proposed solution is to just do
ldd --version. My target platform doesn't haveldd:
$ ldd
sh: can't execute 'ldd': No such file or directory
- Another proposed solution is to look at
__GLIBC__and__GLIBC_MINOR__-- but these also appear to come fromlibc-version.h, which doesn't exist in my cross-toolchain, as described above.
My cross-toolchain seems to only provide libc.a, not libc.so.
I tried running that libc.a through /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-nm and strings grepping (case-insensitive) for "version" and "libc" but did not find anything that looked like an identifying version.
The last thing I tried was strings /path/to/toolchains/ARM-cortex-m3-4.4/bin/arm-uclinuxeabi-gcc | grep GLIBC, which gave me:
GLIBC_2.3
GLIBC_2.2
GLIBC_2.1
GLIBC_2.0
EGLIBC configuration specifier, serves multilib purposes.
But that solution wasn't highly upvoted, and it also has a comment suggesting that it doesn't really give you the version. I don't really understand this answer or its responding comment, so I don't know what to make of its validity.
Question: given all the above, is there any definitive way to determine the libc version used for cross-compiling for this cross-platform?