On Thu, Oct 13, 2022 at 01:59:52PM +0100, Mark Brown wrote: > The expected users for old toolchains was always users doing something > like building a newer kernel on an old enterprise distro rather than > people actually developing anything AIUI. > Two or three releases seems a bit ambitious, I'm sitting here in front > of a Debian stable system which probably has another year or so of being > the latest release left and it's sitting at GCC 10.2 with the latest > release of GCC being 12.2. Probably also worth noting that GCC did a > 9.5 release in May this year as it went out of their support window. > A quick look suggests that RHEL 7 is at GCC 4.8 (so running into trouble > anyway), RHEL 8 at 8.x, SLES looks like it makes newer compilers > available even for the old releases (eg, there's GCCs up to 10 available > for SLES 12 AFAICT). Ubuntu 16.04 does seem to use GCC 5 but it's on > extended security support at this point, their 18.04 is at GCC 7.4 from > the looks of it. The thing is, do we really want to be catering to this? In the first place, enterprise users and enterprise kernels are already doing freaky things, forked to no end. But moreover, do we actually want to support people building the kernel with a different compiler than most of us develop with? In a basic way, that just seems like a recipe for disaster. It's also easy, nearly trivial, to download toolchains. Arnd provides a bunch with his crosstool. "Must use a toolchain from your distro" is a requirement that affects nobody. So I just think we're thinking about this all wrong. It doesn't matter what's available on the distros. It matters what the most reasonable compiler to develop with is, first of all. And secondly, it matters that this compiler is easily available for users to download in a variety of settings need-be. And I'm pretty sure this latter part is already the case. Plus, as I mentioned earlier, this is already the model we're going toward by virtue of Rust (and to a small extent, Clang) invading. Jason
