archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <>
To: Mark Brown <>
	Linux Kbuild mailing list <>,
	LKML <>
Subject: Re: gcc 5 & 6 & others already out of date?
Date: Thu, 13 Oct 2022 09:23:36 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

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.


  reply	other threads:[~2022-10-13 15:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-13  1:36 gcc 5 & 6 & others already out of date? Jason A. Donenfeld
2022-10-13 12:22 ` David Laight
2022-10-13 12:59 ` Mark Brown
2022-10-13 15:23   ` Jason A. Donenfeld [this message]
2022-10-13 16:18     ` Willy Tarreau
2022-10-14  4:28       ` David Laight
2022-10-14  5:27         ` Willy Tarreau
2022-10-13 16:26     ` Mark Brown
2022-10-13 16:37       ` Jason A. Donenfeld
2022-10-13 16:51         ` Willy Tarreau
2022-10-13 17:16         ` Mark Brown
2022-10-13 18:38           ` Florian Weimer
2022-10-13 20:23             ` Mark Brown
2022-10-14  6:15               ` Florian Weimer
2022-10-13 18:39     ` Florian Weimer
2022-10-13 21:03       ` Nick Desaulniers
2022-10-14  6:37         ` Florian Weimer
2022-10-13 21:08 ` Nick Desaulniers
2022-10-14  1:31   ` Jason A. Donenfeld
2022-10-14 11:13   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).