Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 724484 - sys-apps/portage fails to call CTARGET for strip when used with cross ebuilds
Summary: sys-apps/portage fails to call CTARGET for strip when used with cross ebuilds
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 700884
  Show dependency tree
 
Reported: 2020-05-21 19:06 UTC by Jory A. Pratt
Modified: 2020-05-21 21:44 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log showing strip calling CHOST instead of CTARGET (clean_build.log.xz,26.34 KB, application/x-xz)
2020-05-21 19:06 UTC, Jory A. Pratt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jory A. Pratt gentoo-dev 2020-05-21 19:06:30 UTC
Created attachment 640802 [details]
build.log showing strip calling CHOST instead of CTARGET

Please refer to attachment, spoke with zmedico on irc about issue.
Comment 1 Zac Medico gentoo-dev 2020-05-21 19:14:16 UTC
(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)'
Comment 2 Mike Gilbert gentoo-dev 2020-05-21 19:27:20 UTC
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}.
Comment 3 Mike Gilbert gentoo-dev 2020-05-21 19:32:18 UTC
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
Comment 4 Arfrever Frehtes Taifersar Arahesis 2020-05-21 21:30:17 UTC
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.)
Comment 5 Sergei Trofimovich gentoo-dev 2020-05-21 21:44:26 UTC
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 /
"""