| Summary: | sys-devel/crossdev - cross-aarch64-unknown-linux-musl/musl-1.1.20 fails to emerge: cc1: error: unknown value ‘native’ for -march | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vincent Hardy <vincent.hardy.be> |
| Component: | Current packages | Assignee: | Gentoo Crossdev team <crossdev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alexander, embedded, herrtimson, jarymut+gentoo.bugs, musl |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://github.com/gentoo/gentoo/pull/12847 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
full build.log
emerge info emerge -pqv musl-1.1.22-r1 ebuild with possible fix musl-1.1.23-r1 ebuild with possible fix |
||
Created attachment 547978 [details]
emerge info
Created attachment 547980 [details]
emerge -pqv
Same thing happens for mips (and mipsel), so I believe it happens for all musl targets. This is a bit hacky, but you have to temporarily switch cflags on your hosts make.conf to those of your target. This makes the compile go, but I really don't know if this produces a legit cross compiler. So far musl ebuilds don't support cross-compilation. glibc workarounds a similar mix of build/host flags by filtering out all unsupported options:
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.28-r5.ebuild#n327
# Make sure host make.conf doesn't pollute us
if is_crosscompile || tc-is-cross-compiler ; then
CHOST=${CTARGET} strip-unsupported-flags
fi
strip-flags
strip-unsupported-flags
You can try the same for musl.
I added a pullrequest for the overlay: https://github.com/gentoo/musl/pull/249 I'm not having any trouble building cross- toolchains with musl - is this a particular issue because of -march=native in your CFLAGS ? Yes, it's because march is added to system-wide flags. Other cross-toolchains I used remove incompatible flags. Musl targets do not. (In reply to Jarek Rymut from comment #9) > Yes, it's because march is added to system-wide flags. Other > cross-toolchains I used remove incompatible flags. Musl targets do not. Thanks for the clarification Could you guys post your combiantions of CHOST and CBUILD from the /usr/CHOST/etc/portage/make.conf, please? I wonder wether this is needed only in cases where there's glibc involved in CBUILD. CHOST=mipsel-unknown-linux-musl CBUILD=x86_64-pc-linux-gnu CHOST=aarch64-unknown-linux-musl CBUILD=x86_64-pc-linux-gnu I think this is only needed in case of CBUILD=glibc Still, can you please give the patched ebuild from the pullrequest a go, to see if that also fixes -march=native? https://github.com/gentoo/musl/pull/249 Ok I'm hitting this problem running crossdev on a musl system. I'll try copying some of the key ebuilds into an overlay, and playing around with options as slyfox suggests.
We also need to fix building glibc toolchains from musl, where the multilib eclass gets in a knot because /usr/lib64 doesn't exist on musl systems (normally) and consequently the new chroot /usr/{CTARGET} ends up proper confused!!
Created attachment 587824 [details] musl-1.1.22-r1 ebuild with possible fix I'm attaching a possible fix for this bug, I'm going to test this soon with armv7: 1. grab a fresh stage, upgrade as needed. 2. build a cross-compile toolchain based on the patched musl-1.1.22-r1 on the host, and cross-emerge musl-1.1.22-r1 for the target. 3. emerge the binary pkg on the target host. 4. emerge -e world for the target, to see wether it triggers something. please report back with your combination of CHOST and CTARGET, so that we can compile a list of working/non-working diff of musl-1.1.22.ebuild: > # Make sure host make.conf doesn't pollute us > if is_crosscompile || tc-is-cross-compiler ; then > CHOST=${CTARGET} strip-unsupported-flags > fi Created attachment 587826 [details] musl-1.1.23-r1 ebuild with possible fix same goes for musl-1.1.23-r1 ; but please be aware of breakage from https://bugs.gentoo.org/690426 I think this is good to go, or is there anyone still having problems with this? The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c3bb292bd123f58758554c23f2d56acae081885 commit 2c3bb292bd123f58758554c23f2d56acae081885 Author: stefson <herrtimson@yahoo.de> AuthorDate: 2019-09-02 16:43:53 +0000 Commit: Anthony G. Basile <blueness@gentoo.org> CommitDate: 2019-09-03 11:18:32 +0000 sys-libs/musl: fix leaking of host cflags into cross-musl Closes: https://bugs.gentoo.org/667126 Signed-off-by: Steffen Kuhn <nielson2@yandex.com> Signed-off-by: Anthony G. Basile <blueness@gentoo.org> sys-libs/musl/musl-1.1.20-r1.ebuild | 6 ++++++ sys-libs/musl/musl-1.1.21.ebuild | 6 ++++++ sys-libs/musl/musl-1.1.22.ebuild | 6 ++++++ sys-libs/musl/musl-1.1.23.ebuild | 6 ++++++ sys-libs/musl/musl-9999.ebuild | 6 ++++++ 5 files changed, 30 insertions(+) |
Created attachment 547976 [details] full build.log I started crossdev -P -v -t aarch64-unknown-linux-musl and finally emerge musl-1.1.20 failed. I got : unrecognized option -march=native