sys-devel/crossdev forces multilib for arm toolchains

[kwhat]

Add support for more specific arm toolchain tripples allowing for USE=-multilib in some scenarios

Closes: https://bugs.gentoo.org/868636
Signed-off-by: Alexander Barker (https://github.com/kwhat) alex@1stleg.com

[kwhat]

This appears to be creating a working toolchain with minimal modification. I still want to do some more testing before considering this for merge, but review is welcome.

This requires a toolchain.eclass patch to work correctly due to the eabi[hs]f stuff.

crossdev-toolchain-eclass.patch

Update 1:

I have been driving this for a couple of day and it works but I had to build armv7m-none-eabihf with something like EXTRA_ECONF="--with-arch=armv7e-m --with-mode=thumb --with-fpu=fpv5-d16" to kind of get what I was expecting. It produces a compiler that does work without but some of the defaults are broken. I think the --with-fpu override is acceptable but I wonder if the toolchain eclass should make more of an effort to fill in --with-arch and --with-mode. I think there is enough here to address the bug filed; it is possible to make toolchains with these fixes here if the end user adds a little EXTRA_ECONF.

[thesamesam]

Could you rebase? Not sure if Matt's changes in f3b5cc3 mean that you need to rejig this either.

[kwhat]

I am pretty sure its exactly the same fix I had put in but I want to rebuild and retest before merging now. Not sure why this diff is a lot smaller now ☠️

[thesamesam]

Thanks, and sorry. I could've tried resolve it myself but I wasn't sure either.

[kwhat]

This doesn't work anymore and I'm not sure why it broke. I have several more fixes to go in and I'm debating on just running a custom fork rt now.

[thesamesam]

Well, I'm happy to take a fix if you can come up with one, but it's up to you.

[kwhat]

Alright putting back in the eclass pathces fixed the compile but the CFLAGS are borked again with USE=custom-cflags which I had fixed but I am not sure if sent that fix to you guys yet.

[kwhat]

My checks are all passing as of this morning.

[thesamesam]

Thanks. It's a busy few days and it will be at least for the rest of this week for me. But I can try look after that.

In the meantime, can you check the armv*CI failure for this PR?

[kwhat]

These failures build locally so should work once we figure out what to do with toolchain.eclass. I am in no rush to merge this yet. I did a bunch of digging into all of the different architectures this can support and I am starting to appreciate why only the multilib target is supported. I originally thought that *-eabi[hs]f would be enough to determine if we should use multilib, but I think there needs to be a little more to it. Something like armv6m-none-eabi would be a valid with EXTRA_ECONF="--disable-multilib --with-arch=armv6s-m --with-mode=thumb --with-float=soft", anything that doesn't have an fpu is technically -eabi.

[kwhat]

Alright, I feel like this is ready for review. The toolchain updates where significantly more involved than I anticipated. I added a lot of notes to #976081, sorry it's so long winded. I would like to figure out a way to run the entire g/h test suite locally, but I haven't had much luck with it yet. I have spot checked the bulk of the arm targets locally, a script I wrote to check all of them is currently running.