gcc 5 & 6 & others already out of date?

gcc 5 & 6 & others already out of date?

[Jason A. Donenfeld]

Hi,

I've been working on a (still in development) patch that tries to
apply a few compile-time constant folding tricks to a widely used
library function, so I wanted to make sure my trickery worked across
all supported gcc versions for as many call sites as possible.
Naturally, this means allyesconfig builds on the monster box.

So all went well with a recent gcc and with clang. Then I tried gcc 5
and gcc 6, and it wasn't fine. But it wasn't not fine because of my
new code -- that all compiled just fine. Rather, it wasn't fine
because of a modicum of other odd errors and fatal warnings
throughout. I tried this with gcc 5 and gcc 6 and then got bored. I
could test more versions need be. And I guess I could submit bug
reports or write patches or work on fixing all those, if I actually
cared about it. But I don't really care about it, and apparently
neither does anybody else, because this isn't brand new breakage. And
this all got me thinking...

Linus merged Rust for 6.1, and this relies on unstable features. We're
in for a world of pain, I'm sure, and who knows where this is going to
lead. But what seems clear is that as we figure out how to make Rust
work with the kernel (if we can manage to figure that out, that is),
we're going to likely be bumping the minimum compiler version as the
upstream Rust people implement things we need. And while Rust is used
for nothing today, soon it'll be used for things not exactly optional
for certain segments of users - for example, that Apple GPU driver.
The slow stable days of C are coming to an end, it would seem.

But also, it's not just Rust. Clang support has been an incremental
thing, and the kernel has dropped old Clang versions as they no longer
make sense. Heck, the new KCFI implementation requires bleeding edge
Clang, and the kernel dropped support for the old implementation. So
clearly, the people that use Clang want to use new Clang, not crusty
Clang, and that's sort of the whole point of that being there.

And then there's old trusty gcc. Gcc also improves according to a nice
cadence, and we know people are using later gccs because nobody is
catching the build errors from old gccs. So let's stop pretending we
support old compilers. We clearly don't. Maybe some subset of code
does, but by and large, I doubt many developers are actually daily
driving gcc 5.1 and doing allyesconfig builds with it. Yes, many are
rightfully cautious of gcc 12 and stick with gcc 11 still, and that's
reasonable, but 11 or even 10 is still way larger than 5.1.

The truth is, people tend to use more recent toolchains. And if Clang
hasn't broken the will of the stranglers, then surely Rust will.

So, what are your thoughts on just abandoning this charade all
together, and saying that we support the last 2 or 3 releases of a
compiler (and related toolchain - binutils and such) at the time of
the kernel's release, and admit that our C is a moving target, just as
our Rust inevitably will be. Then we don't have to have these tortured
conversations every few years about 4.9 or 5.1 or 6.3 or whatever
enterprise [il-]logic has tended to dictate how things have worked
until now.

As usual, feel free to chase me off with pitchforks. I'm sure some
RHEL folks hate this. But I think it's at least worth consideration.

Jason

RE: gcc 5 & 6 & others already out of date?

[David Laight]

From: Jason A. Donenfeld
> Sent: 13 October 2022 02:37
...
> And then there's old trusty gcc. Gcc also improves according to a nice
> cadence, and we know people are using later gccs because nobody is
> catching the build errors from old gccs. So let's stop pretending we
> support old compilers. We clearly don't. Maybe some subset of code
> does, but by and large, I doubt many developers are actually daily
> driving gcc 5.1 and doing allyesconfig builds with it. Yes, many are
> rightfully cautious of gcc 12 and stick with gcc 11 still, and that's
> reasonable, but 11 or even 10 is still way larger than 5.1.
> 
> The truth is, people tend to use more recent toolchains. And if Clang
> hasn't broken the will of the stranglers, then surely Rust will.

Developers might use recent toolchains, but users are much
more likely to use the one in the distribution they have installed.

Working out how to build a kernel is hard enough.
Requiring non-standard versions of gcc is a PITA.
Remember that you can load a current kernel on quite
old userspace.
There can be all sorts of reasons for wanting to keep building
non-kernel 'stuff' with the default toolchain.

Anyone using clang almost certainly has to download a recent
version - but this is not true of gcc.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: gcc 5 & 6 & others already out of date?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3162 bytes --]

On Wed, Oct 12, 2022 at 07:36:40PM -0600, Jason A. Donenfeld wrote:

> But also, it's not just Rust. Clang support has been an incremental
> thing, and the kernel has dropped old Clang versions as they no longer
> make sense. Heck, the new KCFI implementation requires bleeding edge

I suspect that if clang starts being the default system compiler for one
of the distros with longer support windows we'll start treating it more
like GCC, right now clang is in the position where for the most part
people using clang are actively seeking it out and explicitly picking a
clang version rather than just trying to build the kernel with whatever
compiler they got by default.

> And then there's old trusty gcc. Gcc also improves according to a nice
> cadence, and we know people are using later gccs because nobody is
> catching the build errors from old gccs. So let's stop pretending we
> support old compilers. We clearly don't. Maybe some subset of code
> does, but by and large, I doubt many developers are actually daily
> driving gcc 5.1 and doing allyesconfig builds with it. Yes, many are
> rightfully cautious of gcc 12 and stick with gcc 11 still, and that's
> reasonable, but 11 or even 10 is still way larger than 5.1.

> The truth is, people tend to use more recent toolchains. And if Clang
> hasn't broken the will of the stranglers, then surely Rust will.

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.

> So, what are your thoughts on just abandoning this charade all
> together, and saying that we support the last 2 or 3 releases of a
> compiler (and related toolchain - binutils and such) at the time of

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.

> the kernel's release, and admit that our C is a moving target, just as
> our Rust inevitably will be. Then we don't have to have these tortured
> conversations every few years about 4.9 or 5.1 or 6.3 or whatever
> enterprise [il-]logic has tended to dictate how things have worked
> until now.

> As usual, feel free to chase me off with pitchforks. I'm sure some
> RHEL folks hate this. But I think it's at least worth consideration.

I do think it would be helpful to track where the choices of baseline
versions are coming from, if nothing else that'd probably make the
conversations about upgrading them easier even if we don't actually bump
them until we run into trouble.

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: gcc 5 & 6 & others already out of date?

[Jason A. Donenfeld]

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

Re: gcc 5 & 6 & others already out of date?

[Willy Tarreau]

Hi Jason,

On Thu, Oct 13, 2022 at 09:23:36AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 13, 2022 at 01:59:52PM +0100, Mark Brown wrote:
> 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.

It's important not to confuse enterprise users and enterprise distros.
The users are precisely not forking things to death, they're using
solely what they're being fed by the distro (and possibly other vendors).

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

I think it's important to make *reasonable efforts* for this, yes.
For example at work we're building appliances for which we test and
validate working combinations of gcc+binutils+glibc+kernel, and once
we've found a sane working combination that doesn't break userspace
too much, we stick to it and we use it for both kernel AND userland.

I must confess that having had to upgrade the toolchain in the past
*only* for the kernel was annoying. It's never wasted since it forces
to do some of the update work, and there could be pretty valid reasons
for this. However being forced to patch userland code to please gcc
just because kernel developers decided to switch again based on what
their distro ship is a needless pain.

Another thing, kernels can take time to build, and people do setup
some distributed toolchains. You may remember the presentation of
my build farm at Kernel Recipes. Once you've spent quite some time
on canadian cross builds and your setup is fine, you cross fingers
for it to last as long as possible. And typically when I worked on
the floppy fixes a few years ago that was when my compiler stopped
being supported. I started by spending several week-ends trying to
update my setup before going back to real work. Again I know that
sometimes this is need and it was my task to devote some time to
this. But let's not have to do this too often unless really needed.

Usually it's considered fair to drop support for a compiler when the
build issues that pop up are too difficult to fix, and/or when they
require quite some work and you figure that if nobody complained for
a long time it definitely means nobody's using it anymore.

But even on personal projects I continue to support older compilers
because once in a while someone asks me if I can help them build on
$RANDOM_OLD_SYSTEM, and I figured that the diversity provided by
exotic environments sometimes uncover interesting issues.

So I'd really suggest to stick to the good old "as long as it works
and doesn't involve unreasonable effort, let's consider it still
works".

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

That's also the model where people routinely do:

    $ curl github.com/blah | sudo sh

that makes everything very hardly reproducible and is not necessarily
a good approach all the time.

It might be reasonable to reduce the compiler spectrum a bit but losing
users on the way and making it more painful to them to occasionally test
a kernel is neither nice nor profitable to get reports.

I do still remember the days where one needed to build a kernel using
kgcc because the distro's one didn't work, and quite frankly, that was
a total mess and it did discourage quite a few people I knew.

Just my two cents,
Willy

RE: gcc 5 & 6 & others already out of date?

[David Laight]

From: Willy Tarreau
> Sent: 13 October 2022 17:18
...
> That's also the model where people routinely do:
> 
>     $ curl github.com/blah | sudo sh

Anyone doing that wants their head examined....
I'm not sure I'd trust any source of files enough for that.

Maybe some things get run as root, and maybe they might
do nasty things, but running random downloaded scripts
is as bad as clicking on links in outlook.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: gcc 5 & 6 & others already out of date?

[Willy Tarreau]

On Fri, Oct 14, 2022 at 04:28:10AM +0000, David Laight wrote:
> From: Willy Tarreau
> > Sent: 13 October 2022 17:18
> ...
> > That's also the model where people routinely do:
> > 
> >     $ curl github.com/blah | sudo sh
> 
> Anyone doing that wants their head examined....

Most of the time they have no clue what they're doing, they just
copy-paste installation instructions. You find hundreds of projects
documenting this as the installation procedure, often in the nodejs
world it seems, and the fist complaint in general is not that it's a
bad practise but that it doesn't work on Mac! Random examples from
google's first page:

   https://gist.github.com/btm/6700524
   https://github.com/rclone/rclone/issues/3922
   https://gist.github.com/andrepg/71a15e915846acd41370e275eadb0478
   https://github.com/shellspec/shellspec/blob/master/install.sh

This one looks like a trap, it searches from local vulnerabilities
and suggests to be installed like this:

   https://github.com/carlospolop/PEASS-ng/blob/master/linPEAS/README.md

> I'm not sure I'd trust any source of files enough for that.

That's for a targetted audience.

> Maybe some things get run as root, and maybe they might
> do nasty things, but running random downloaded scripts
> is as bad as clicking on links in outlook.

Yes, or even despite a full end-to-end trust you still have the risk of
a truncated script, which you'd rather not face during rm -rf /tmp/blah.

Anyway we're getting out of topic here.

Willy

Re: gcc 5 & 6 & others already out of date?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4141 bytes --]

On Thu, Oct 13, 2022 at 09:23:36AM -0600, Jason A. Donenfeld wrote:
> 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.

> 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

My understanding with that use case was that it was precisely people who
were happy enough with a disro userspace but wanted something more
mainline for their kernel for whatever reason but quite often involving
not having all the fun enterprise patching.  One use case I've heard of
is doing semi-embedded stuff where you need kernel support for the
hardware but everything exciting in userspace is locally developed
software.

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

Personally I do frequently use my distro compiler FWIW.

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

I wouldn't be so sure about that if you express the requirement as
"must have control over and reproducability for the build environment"
instead, it's a lot easier to get everything by installing distro
packages than to have to introduce custom steps (having packaged
versions of things even if not provided by the distro themselves helps
here).  It's not that it's impossible for people to get things set up
but it's definitely a barrier - I know there's a bunch of projects I
should look at but don't do anything with precisely because it's too
much work to figure out how to install and keep up to date whatever
shiny new build dependencies they're requiring without messing up any of
the distro provided stuff.  Those do tend to be things other than the
basic C compiler though.

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

There's definitely tarballs for the kernel side stuff which is fine for
development use, I'm not aware of packaged versions.  There are things
like tuxmake which will run the builds in containers which is another
approach to the problem, though again that'd require people to control
both the tool version and the container versions which might not be much
of a win compared to dealing with tarballs.

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

Yeah, like I say I suspect that the way we handle dependencies for those
might change if people were using those things without actively seeking
them out.  You can flip things around and say that the reason we're
happy to upgrade the base requirement for clang is that people using it
are actively seeking it out already so there's not the demand for
working with older versions.  At least for me it also helps that clang
provides apt repositories for current versions.

Note that I'm not saying we shouldn't upgrade our requirements at all,
just that I'm worrying about going from one extreme to the other in
terms of version requirements - it feels like there's a step change when
you move from things you can get in current release distros people are
likely to be using to things that will require a large proportion of
people to install extra stuff.  At the minute we're more at the other
end where it can be hard to figure out who'd even have the oldest
versions we support without deliberately seeking them out and keeping
them going is noticably making work for people.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: gcc 5 & 6 & others already out of date?

[Jason A. Donenfeld]

On Thu, Oct 13, 2022 at 05:26:04PM +0100, Mark Brown wrote:
> Note that I'm not saying we shouldn't upgrade our requirements at all,
> just that I'm worrying about going from one extreme to the other in
> terms of version requirements - it feels like there's a step change when
> you move from things you can get in current release distros people are
> likely to be using to things that will require a large proportion of
> people to install extra stuff.  At the minute we're more at the other
> end where it can be hard to figure out who'd even have the oldest
> versions we support without deliberately seeking them out and keeping
> them going is noticably making work for people.

Regarding "one extreme to the other", I suspect that in spite of my
arguments, which would seem to justify an extreme, the actual thing I
suggested is a bit more moderate: let's support the latest 2 or 3 gccs
at the time of kernel release. If we choose 3, that's roughly 3 years of
gccs, right? 3 years seems like a fairly long amount of time.

Jason

Re: gcc 5 & 6 & others already out of date?

[Willy Tarreau]

On Thu, Oct 13, 2022 at 10:37:21AM -0600, Jason A. Donenfeld wrote:
> On Thu, Oct 13, 2022 at 05:26:04PM +0100, Mark Brown wrote:
> > Note that I'm not saying we shouldn't upgrade our requirements at all,
> > just that I'm worrying about going from one extreme to the other in
> > terms of version requirements - it feels like there's a step change when
> > you move from things you can get in current release distros people are
> > likely to be using to things that will require a large proportion of
> > people to install extra stuff.  At the minute we're more at the other
> > end where it can be hard to figure out who'd even have the oldest
> > versions we support without deliberately seeking them out and keeping
> > them going is noticably making work for people.
> 
> Regarding "one extreme to the other", I suspect that in spite of my
> arguments, which would seem to justify an extreme, the actual thing I
> suggested is a bit more moderate: let's support the latest 2 or 3 gccs
> at the time of kernel release. If we choose 3, that's roughly 3 years of
> gccs, right?

Ideally we should support at the very least those of the oldest
supported LTS kernels, because one thing for LTS users is that we
also want to encourage them to try new kernels, and if they can't
build newer kernels from the start we all know they'll give up
very quickly. And this eases the backport to those kernels as it
is expected that a mainline fix will support those versions (even
if it may break from time to time by accident, but the intent is
there).

> 3 years seems like a fairly long amount of time.

For a developer changing their distro every 6 months, possibly. Not
for users who took time to stabilize their system to something working
and who are curious about what the new kernel provides from time to
time.

Willy

Re: gcc 5 & 6 & others already out of date?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

On Thu, Oct 13, 2022 at 10:37:21AM -0600, Jason A. Donenfeld wrote:

> Regarding "one extreme to the other", I suspect that in spite of my
> arguments, which would seem to justify an extreme, the actual thing I
> suggested is a bit more moderate: let's support the latest 2 or 3 gccs
> at the time of kernel release. If we choose 3, that's roughly 3 years of
> gccs, right? 3 years seems like a fairly long amount of time.

I was looking at your suggestion there - as a Debian user that feels a
touch enthusiastic (though practically probably not actually a problem)
since it's not too far off the release cadence, current Debian is at GCC
10 and we're not due for another release till sometime next year which
will be right on the three years.  There does also seem to be a
contingent of people running enterprise distros managed by an IT
department or whatever who may take a while to get round to pushing out
new versions so for example might still for example be running Ubuntu
20.04 rather than 22.04 (never mind the people I know are sitting on
18.04 but that's another thing).  

If we went for three years extreme would probably be an overstatment but
it's definitely an active push.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: gcc 5 & 6 & others already out of date?

[Florian Weimer]

* Mark Brown:

> On Thu, Oct 13, 2022 at 10:37:21AM -0600, Jason A. Donenfeld wrote:
>
>> Regarding "one extreme to the other", I suspect that in spite of my
>> arguments, which would seem to justify an extreme, the actual thing I
>> suggested is a bit more moderate: let's support the latest 2 or 3 gccs
>> at the time of kernel release. If we choose 3, that's roughly 3 years of
>> gccs, right? 3 years seems like a fairly long amount of time.
>
> I was looking at your suggestion there - as a Debian user that feels a
> touch enthusiastic (though practically probably not actually a problem)
> since it's not too far off the release cadence, current Debian is at GCC
> 10 and we're not due for another release till sometime next year which
> will be right on the three years.

Debian also has Clang 13, presumably for building Rust and Firefox.

> There does also seem to be a contingent of people running enterprise
> distros managed by an IT department or whatever who may take a while
> to get round to pushing out new versions so for example might still
> for example be running Ubuntu 20.04 rather than 22.04 (never mind the
> people I know are sitting on 18.04 but that's another thing).

The enterprise distributions have toolchain modules or toolsets that you
can install, all nicely integrated.  You'd probably consider those
versions too new. 8-/   I expect it's mostly an education issue, raising
awareness of what's available from vendors.   (glibc versions are a
different matter, but I don't think dropping support for historic
versions on build hosts is on the table, so that should be relevant.)

Compiler version requirements probably impact the people most who build
their own toolchains for whatever reason.  There must be unusual targets
where the upstream toolchain currently cannot build a booting kernel,
for instance.  If you require newer toolchain features in generic code,
it could bring some temporary suffering to those people: they need to
fix their toolchain before they can contribute again to the mainline
kernel.

Thanks,
Florian

Re: gcc 5 & 6 & others already out of date?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Thu, Oct 13, 2022 at 08:38:02PM +0200, Florian Weimer wrote:
> * Mark Brown:
> > On Thu, Oct 13, 2022 at 10:37:21AM -0600, Jason A. Donenfeld wrote:

> > I was looking at your suggestion there - as a Debian user that feels a
> > touch enthusiastic (though practically probably not actually a problem)
> > since it's not too far off the release cadence, current Debian is at GCC
> > 10 and we're not due for another release till sometime next year which
> > will be right on the three years.

> Debian also has Clang 13, presumably for building Rust and Firefox.

Ah, so it does - nice!

> > There does also seem to be a contingent of people running enterprise
> > distros managed by an IT department or whatever who may take a while
> > to get round to pushing out new versions so for example might still
> > for example be running Ubuntu 20.04 rather than 22.04 (never mind the
> > people I know are sitting on 18.04 but that's another thing).

> The enterprise distributions have toolchain modules or toolsets that you
> can install, all nicely integrated.  You'd probably consider those
> versions too new. 8-/   I expect it's mostly an education issue, raising
> awareness of what's available from vendors.   (glibc versions are a
> different matter, but I don't think dropping support for historic
> versions on build hosts is on the table, so that should be relevant.)

Yeah, I found the ones for SLES easily enough but not the ones for RHEL
or Ubuntu.  Perfectly prepared to believe they're there though, it does
seem like sometihng users might want.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: gcc 5 & 6 & others already out of date?

[Florian Weimer]

* Mark Brown:

>> The enterprise distributions have toolchain modules or toolsets that you
>> can install, all nicely integrated.  You'd probably consider those
>> versions too new. 8-/   I expect it's mostly an education issue, raising
>> awareness of what's available from vendors.   (glibc versions are a
>> different matter, but I don't think dropping support for historic
>> versions on build hosts is on the table, so that should be relevant.)
>
> Yeah, I found the ones for SLES easily enough but not the ones for RHEL
> or Ubuntu.  Perfectly prepared to believe they're there though, it does
> seem like sometihng users might want.

For what it's worth, it's devtoolset-11-gcc or gcc-toolset-11-gcc,
depending on the OS version.  The “11” is the GCC version, new versions
become available in the fall, about half a year after the upstream
release.  Old versions remain installable (even in parallel), but drop
out of official support fairly quickly (at least compared to our usual
support timelines).

Thanks,
Florian

Re: gcc 5 & 6 & others already out of date?

[Florian Weimer]

* Jason A. Donenfeld:

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

But not everything will be built with the cross-compiler.  For the
kernel build tools and other userspace components, you'll need a native
toolchain that can build programs that can actually run on the build
host.  At the very least, this means that the right search paths have to
be baked into the tools, and I'm not sure this will happen automatically
for popular distributions.  (I only know that it wouldn't happen for
glibc, but you can't really rebuild that.)  This seems unexplored
territory to me.  The existence of working cross-tools doesn't tell us
much how native builds and integration with installed native libraries
will play out in practice.

There's also going to be much greater variance of compilers people
actually use if everyone just picks an upstream release branch snapshot
at some point in time.

None of this may be sufficient reason to support old toolchains.  But if
you require more recent versions, you really should tell people to
upgrade to new distributions, or use newer toolchain versions
specifically built for the distribution by their distribution vendor.
And not to try to build their own toolchain.


Thanks,
Florian

Re: gcc 5 & 6 & others already out of date?

[Nick Desaulniers]

On Thu, Oct 13, 2022 at 11:44 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Jason A. Donenfeld:
>
> > 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.
>
> But not everything will be built with the cross-compiler.  For the
> kernel build tools and other userspace components, you'll need a native
> toolchain that can build programs that can actually run on the build
> host.

... when using GCC. We don't have this pain when using clang.

https://docs.kernel.org/kbuild/llvm.html#llvm-utilities

i.e.
$ make ARCH=arm LLVM=1

will build with one instance of a clang binary (and ld.lld and
llvm-objcopy etc.) for Target AND Host.  No need for multiple
toolchain binaries.
-- 
Thanks,
~Nick Desaulniers

Re: gcc 5 & 6 & others already out of date?

[Florian Weimer]

* Nick Desaulniers:

> On Thu, Oct 13, 2022 at 11:44 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Jason A. Donenfeld:
>>
>> > 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.
>>
>> But not everything will be built with the cross-compiler.  For the
>> kernel build tools and other userspace components, you'll need a native
>> toolchain that can build programs that can actually run on the build
>> host.
>
> ... when using GCC. We don't have this pain when using clang.
>
> https://docs.kernel.org/kbuild/llvm.html#llvm-utilities
>
> i.e.
> $ make ARCH=arm LLVM=1
>
> will build with one instance of a clang binary (and ld.lld and
> llvm-objcopy etc.) for Target AND Host.  No need for multiple
> toolchain binaries.

I'm sure it's nice if it works.  But someone has to do the distribution
integration work.  If that has already happened upstream, that's great.
(There are many little details which may or may not matter for kernel
builds, e.g., static libraries have to be PIC or PIE because Clang now
defaults to PIE links.)

But it's also sort of irrelevant in the context of this thread.
<https://llvm.org/docs/GettingStarted.html#software> says GCC 7 is
required, and this:

| LLVM is very demanding of the host C++ compiler, and as such tends to
| expose bugs in the compiler. We also attempt to follow improvements
| and developments in the C++ language and library reasonably
| closely. As such, we require a modern host C++ toolchain, both
| compiler and standard library, in order to build LLVM.

So a LLVM build from upstream sources won't be an easy escape hatch if
the kernel bumps toolchain version requirements.

Historically, GCC has been much more conservative when it comes to host
toolchain requirements.  But there are other traps (fixincludes can have
nasty side effects, for example).

I'm not saying the kernel shouldn't change version requirements.  But I
do think it's unreasonable to expect that people will be able to build
their own newer toolchains from upstream sources as a workaround.

Thanks,
Florian

Re: gcc 5 & 6 & others already out of date?

[Nick Desaulniers]

On Wed, Oct 12, 2022 at 6:37 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> Hi,
>
> I've been working on a (still in development) patch that tries to
> apply a few compile-time constant folding tricks to a widely used
> library function, so I wanted to make sure my trickery worked across
> all supported gcc versions for as many call sites as possible.

I'd imagine the kernel's inconsistent use of -ffreestanding per
architecture would be a blocker, if by library function you're
referring to a symbol that would typically be provided by the libc?

Do you have more info about what the specific issue you've observed is?

> Naturally, this means allyesconfig builds on the monster box.
>
> So all went well with a recent gcc and with clang. Then I tried gcc 5
> and gcc 6, and it wasn't fine. But it wasn't not fine because of my
> new code -- that all compiled just fine. Rather, it wasn't fine
> because of a modicum of other odd errors and fatal warnings
> throughout. I tried this with gcc 5 and gcc 6 and then got bored. I
> could test more versions need be. And I guess I could submit bug
> reports or write patches or work on fixing all those, if I actually
> cared about it. But I don't really care about it, and apparently
> neither does anybody else, because this isn't brand new breakage. And
> this all got me thinking...

Are the defconfigs totally broken with gcc-5 and gcc-6 and no one has noticed?

I wonder what versions of GCC KernelCI and linux kernel robot are testing with?

We have to maintain CI for all supported clang versions. You can see a
2D slice of our 5D build matrix: https://clangbuiltlinux.github.io/.
"I've never seen so much red in the galaxy!" "Hey, get back to work!"

We'd like to have the large window of supported versions that GCC
currently has; Clang's release cycle is also different from GCC's
though.  I wouldn't point to clang's smaller version support window as
justification for GCC; we'd rather be more like GCC in that sense, not
the other way round!
-- 
Thanks,
~Nick Desaulniers

Re: gcc 5 & 6 & others already out of date?

[Jason A. Donenfeld]

On Thu, Oct 13, 2022 at 02:08:22PM -0700, Nick Desaulniers wrote:
> On Wed, Oct 12, 2022 at 6:37 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > Hi,
> >
> > I've been working on a (still in development) patch that tries to
> > apply a few compile-time constant folding tricks to a widely used
> > library function, so I wanted to make sure my trickery worked across
> > all supported gcc versions for as many call sites as possible.
> 
> I'd imagine the kernel's inconsistent use of -ffreestanding per
> architecture would be a blocker, if by library function you're
> referring to a symbol that would typically be provided by the libc?
> 
> Do you have more info about what the specific issue you've observed is?

As mentioned, I don't really care to follow up with this. But you can if
you want to waste your time. Download a toolchain. Run allmodconfig.
Observe breakage. Shrug your shoulders and wish we would sunset ancient
toolchains.

Jason

Re: gcc 5 & 6 & others already out of date?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Thu, Oct 13, 2022 at 02:08:22PM -0700, Nick Desaulniers wrote:

> Are the defconfigs totally broken with gcc-5 and gcc-6 and no one has noticed?
> 
> I wonder what versions of GCC KernelCI and linux kernel robot are testing with?

KernelCI is using GCC 10 at the minute - it's mainly focused on runtime
testing coverage, we try runtime tests for everything we build so we'd
need to do some work to curtail what runtime test gets run on things
we're mostly doing for build coverage.  IIRC Linaro were supposed to be
doing build coverage of compiler versions at some point but I'm not sure
what the status is or how far back they go if it is running.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]