Re: Build breakage caused by the use of UDB

[Peter Zijlstra]

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.