Re: [meta-arm] Removal of external-arm-toolchain?

On 1/22/25 11:32 AM, Ross Burton via lists.yoctoproject.org wrote:
> Hi,
> 
> It’s that time of the year where I grumble about external-arm-toolchain.  This is the recipe that lets you unpack the Arm binary GCC releases, and tell yocto to use that directory as the cross compiler.
> 
> This time:
> 
> 1) systemd fails to compile as the kernel headers it has don’t include SIOCGSTAMP_OLD (added in linux 5.2)
> 
> 2) There is no real support for locales. It ships locale files but they’re generated by a separate recipe in core and those packages don’t get generated by e-a-t.  This means many of oe-core’s ptest recipes fail because of unexpected dependencies on eg locale-base-en-gb.
> 
> 3) The virtual namespace changes that landed yesterday in core meant it needs updating.
> 
> I’ve started work on (3) but discovered (1) and (2) whilst trying to do a test build.
> 
> So I’m again thinking we should remove external-arm-toolchain from meta-arm. My argument for removing it:
> 
> 1) Whilst it’s a binary release of GCC from Arm, it’s actually almost identical to upstream. Yocto can already build a newer version of upstream, which can be patched rapidly to fix bugs.
> 
> 2) Some pieces of the binary release can be very old: the kernel headers in the 13.2 build were from linux 4.19.
> 
> 3) The binary release has limited platforms: you can only target 32-bit arm on x86-64 or aarch64 hosts, and 64-bit arm on x86-64 hosts.
> 
> 4) Trying to force a round peg (binary toolchain) into a square hole (the implicit interface exposed by yocto’s gcc recipes) is going to be a constant battle.
> 
> 5) Given the problems I found it appears out CI is the main user of it, and that CI coverage is explicitly minimal (disables ptest because we can’t build a target gcc either).
> 
> My understanding is that TI were active users of the binary toolchain for customers who appreciated the speed improvement by not having to compile a cross compiler, but I don’t believe the latest releases of their product support this.  Also this is a prime use case for sstate, in particular the public yocto state server which can be used to fetch all the native tools, not just the compiler.
> 

That is correct, we have moved away from external/binary toolchains.
+Denys had some comments on it you can find here[0] on why we (TI)
used it previously and why we do not anymore.

Andrew

[0] https://lists.yoctoproject.org/g/meta-arago/message/14443

> So, would anyone seriously object if I sent a patch to remove the external-arm-toolchain recipe? This would only be for master, we wouldn’t retroactively remove it from the stable branches.
> 
> Cheers,
> Ross
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#6342): https://lists.yoctoproject.org/g/meta-arm/message/6342
> Mute This Topic: https://lists.yoctoproject.org/mt/110756921/3619733
> Group Owner: [email protected]
> Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [[email protected]]
> -=-=-=-=-=-=-=-=-=-=-=-
>