In bug #645626 a need arose to extract a string out of a cross-compiled binary. Previously, this was done by executing the binary and parsing its output, but this does not work when the build platform does not support the executable format used by the target. (In this case, an ARMv5 binary on an AMD64 host.) Instead, it was found that using the `strings` utility (part of `binutils`) could extract that same string without requiring the binary to be executed by the build host. tc-getSTRINGS has a trivial implementation: # @FUNCTION: tc-getSTRINGS # @USAGE: [toolchain prefix] # @RETURN: name of the strings program tc-getSTRINGS() { tc-getPROG STRINGS strings "$@"; } #… # @FUNCTION: tc-getBUILD_STRINGS # @USAGE: [toolchain prefix] # @RETURN: name of the strings program for building binaries to run on the build machine tc-getBUILD_STRINGS() { tc-getBUILD_PROG STRINGS strings "$@"; }
> In bug #645626 a need arose to extract a string out of a cross-compiled binary Can you explain here a bit what exactly you need to extract? It's a bit strange you don't know the result before building the package or while inspecting gcc -dumpspecs: gcc -dumpspecs | fgrep ld glibc ebuild knows a bit about ld.so: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain-glibc.eclass#n1194 strings is a very crude tool. It might make sense to have a wrapper for it. It feels like objdump or readelf would do the same with more precision.
there's no need to use the cross-compiler's version of strings. all strings in the toolchains work the same. so you could just run `strings` in the ebuild safely. there's also no need for users to override $STRINGS or $BUILD_STRINGS themselves. whether `strings` is the right tool for the job can be left for discussion in the referenced bug.
