linux-kernel - Re: Build breakage caused by the use of UDB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251217132217.GF3707891@noisy.programming.kicks-ass.net>
Date: Wed, 17 Dec 2025 14:22:17 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jean Delvare <jdelvare@...e.de>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: Build breakage caused by the use of UDB

On Wed, Dec 17, 2025 at 02:10:37PM +0100, Jean Delvare wrote:
> Hi Peter,
> 
> On Wed, 17 Dec 2025 13:47:13 +0100, Peter Zijlstra wrote:
> > On Wed, Dec 17, 2025 at 01:35:36PM +0100, Peter Zijlstra wrote:
> > > On Wed, Dec 17, 2025 at 12:44:23PM +0100, Jean Delvare wrote:  
> > > > I must confess this is all way beyond me and I have no idea how this
> > > > change can cause such a build failure, but it does. If it matters, my
> > > > compiler is gcc 8.2.1.  
> > > 
> > > Well, that is somewhat unexpected. None of the build robots fingered
> > > this. Is there a particular .config I should try?
> > > 
> > > I don't seem to have 8.2.1 at hand, but I'll try with 8.3.0.  
> > 
> > I had to (obviously) enable the RTL8192 bits, but then, yes. gcc-8 fails
> > to build this while gcc-10 doesn't seem to have any problems (for some
> > reason my random dev machine of the day doesn't seem to have gcc-9).
> 
> As an additional data point, clang 17.0.6 builds the kernel just fine
> for me.

Yeah, everything except gcc-8 so far. It really is a weird compiler
issue.

> > Let me prod at this for a bit. But also, is there a good reason you're
> > using this stone-age compiler? :-) And yes, its our minimum supported,
> > so I suppose I should go fix, but other than build testing, you really
> > shoulnd't be using it.
> 
> Actually the default C compiler on my openSUSE Leap 15.6 system is even
> gcc 7, I had to manually install gcc 8 and use CC= because gcc 7 is no
> longer supported for upstream kernel builds. I think Leap only changes
> the default compiler on major version changes, and Leap 15.0 was
> released 7.5 years ago.
> 
> If gcc 8 is considered too old, that's fine with me, I can switch to
> yet another compiler, but then Documentation/process/changes.rst should
> be updated to reflect that. As long as our documentation says a
> compiler is supported, I am willing to use it to verify if that's
> actually true ;-)

So strictly speaking gcc-8 should indeed build the kernel, and I'll try
and make this thing go away. But even so, you'll not get the best
possible kernel with gcc-8, it misses a ton of features.

I'm not saying you should move to gcc-16, but keeping up with the
compiler isn't a bad idea in general.