Created attachment 640802 [details] build.log showing strip calling CHOST instead of CTARGET Please refer to attachment, spoke with zmedico on irc about issue.
(In reply to Jory A. Pratt from comment #0) > Created attachment 640802 [details] > build.log showing strip calling CHOST instead of CTARGET I'll post some of the messages here for visibility. It calls x86_64-gentoo-linux-musl-strip on cross arm binaries, resulting in "Unable to recognise the format of the input file" errors: > x86_64-gentoo-linux-musl-strip: Unable to recognise the format of the input file `/var/tmp/portage/cross-armv7a-gentoo-linux-musleabihf/musl-1.1.24/image/usr/armv7a-gentoo-linux-musleabihf/usr/lib/Scrt1.o' > x86_64-gentoo-linux-musl-strip: Unable to recognise the format of the input file `/var/tmp/portage/cross-armv7a-gentoo-linux-musleabihf/musl-1.1.24/image/usr/armv7a-gentoo-linux-musleabihf/usr/lib/libc.a(aio.lo)' > x86_64-gentoo-linux-musl-strip: Unable to recognise the format of the input file `/var/tmp/portage/cross-armv7a-gentoo-linux-musleabihf/musl-1.1.24/image/usr/armv7a-gentoo-linux-musleabihf/usr/lib/libc.a(aio_suspend.lo)' > x86_64-gentoo-linux-musl-strip: Unable to recognise the format of the input file `/var/tmp/portage/cross-armv7a-gentoo-linux-musleabihf/musl-1.1.24/image/usr/armv7a-gentoo-linux-musleabihf/usr/lib/libc.a(lio_listio.lo)' > x86_64-gentoo-linux-musl-strip: Unable to recognise the format of the input file `/var/tmp/portage/cross-armv7a-gentoo-linux-musleabihf/musl-1.1.24/image/usr/armv7a-gentoo-linux-musleabihf/usr/lib/libc.a(__cexp.lo)' > x86_64-gentoo-linux-musl-strip: Unable to recognise the format of the input file `/var/tmp/portage/cross-armv7a-gentoo-linux-musleabihf/musl-1.1.24/image/usr/armv7a-gentoo-linux-musleabihf/usr/lib/libc.a(__cexpf.lo)'
This is a bit tricky. Sometimes ${CHOST}-strip is correct, and sometimes it isn't. For example, when building a cross-compiler (like GCC), the resulting object files will be in a format compatible with ${CHOST}-strip, not ${CTARGET}-strip. On the other hand, when cross-compiling the C library, the resulting object files are compatible with ${CTARGET}-strip, not ${CHOST}-strip. I believe the glibc ebuild works around this by setting CHOST=${CTARGET}.
I'm wrong about the glibc workaround. It seems glibc just disables stripping when CHOST != CTARGET. https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.31-r3.ebuild?id=7855184db364245bac32a5820278f9ea95e07d9e#n1184
Simple workaround is to enable USE="multitarget" for sys-devel/binutils. (llvm-strip also has multi-target support, without any USE flag for sys-devel/llvm.)
Generally calling CHOST tools is correct, because you normally do install tools for CHOST. They might generate code for CTARGET and might contain some CTARGET code. Ideally libc ebuilds should never set CTARGET and be always installed via cross-emerge instead of host emerge with CTARGET override and abuse of it as a CHOST. Until libcs and crossdev is transitioned to that scheme we have to add a workaround to all libc ebuilds. glibc for example uses this snippet: """ # Avoid stripping binaries not targeted by ${CHOST}. Or else # ${CHOST}-strip would break binaries build for ${CTARGET}. is_crosscompile && dostrip -x / """
Reassigning to musl per comment 5.
it is entirely possible to strip cross-compiler glibc, and we were. but it was broken by the attempt to fix bug 587296 via commit e14229b10b513a164f8379ff14cc8c644c071f27. it assumed the point of prepallstrip was only related to the libpthread logic, but it wasn't. that's why the RESTRICT & CHOST=CTARGET logic were in there too.
