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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251217141037.2dff77b8@endymion>
Date: Wed, 17 Dec 2025 14:10:37 +0100
From: Jean Delvare <jdelvare@...e.de>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: Build breakage caused by the use of UDB

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.

> 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 ;-)

Thanks,
-- 
Jean Delvare
SUSE L3 Support