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

On Wed, Jan 22, 2025 at 05:32:52PM +0000, Ross Burton via lists.yoctoproject.org wrote:
> Hi,
> 
> It’s that time of the year where I grumble about external-arm-toolchain.  

Heh, we've had this discussion a few times in the past - I see we are coming 
back to it again... :)


> 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

Yes, TI used binary toolchains since the OpenEmbedded Classic days, including 
but not limited to CodeSourcery, Linaro, and lately Arm. While support for 
normal OE-built toolchain was always an option, the default preference for TI 
products was to use a pre-built binary toolchain.

Though, the build speed was not the reason, at least not the main reason. 
It was due to the technical support requirements. OE-built cross toolchain 
was not trusted back in the day and OE is not in the business of providing 
commercial compiler support, like CodeSourcery would, for example.


>, but I don’t believe the latest releases of their product 
> support this.

True, the maintenance and migration from one release to another was a real 
nightmare, pretty much like you are describing above - always needing to fix 
something. All the remaining extra TI customizations (e.g. supporting both 
64-bit and 32-bit external toolchains at the same time, SDK packaging, etc.) 
were finally removed 1.5 years ago:
https://git.yoctoproject.org/meta-arago/commit/?id=6000a07a51053b7685556246f9f5df7ef7714463


That said, it appears there are some other users of external toolchain - there 
was a person from Smile recently fixing some issues with usrmerge support. And 
I just received a personal email from one of our customers inquiring about it 
as well. In other words - there are other interested parties out there...


>  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.

This is probably a topic for another thread, but there are some issues with 
using sstate like that - public yocto sstate server is very slow and just 
checking what is available takes a very long time, plus cross toolchain is not 
a native package and from my experience re-use is quite low in other distros.


> 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.

As one of the meta-arm-toolchain co-maintainers[1], I would not object to 
removing external-arm-toolchain support (the Linux side) from the layer.

[1] https://git.yoctoproject.org/meta-arm/tree/meta-arm-toolchain/README.md#n99


But, besides external-arm-toolchain, there are also recipes in the layer for 
baremetal compilers, which are not proper cross- recipes, but they pretend 
to be native- ones. That's very hacky and there are some drawbacks, while the 
only benefit is speed, as those are also binary pre-builds. I was previously 
suggesting replacing them with a proper baremetal multiconfig usage, like I 
did in meta-ti for K3 platforms. And as I recall, you were interested in that 
solution as well. If that's still the case, please let me know if you need any 
help with that...

Thanks and regards,
Denys