Bug 1127188

Please attach some example.

I am not the right person to be assigned here, so resetting.

BPF UMH needs an userspace header to build. This is provided by glibc but our crosscompilers do not have glibc headers.

I patched the kconfig so this option can be configured and disabled it on master.

If we want to build with this option we either need to fix the crosscompilers or change kbuild to run build tests natively.

We don't have cross-compilers.

That's right. The kernel teams maintain cross-compilers (in Kernel:tools), but AFAICS there is no suitable Bugzilla product for kbuild, so Bugzilla cannot be used to track this issue.

(In reply to Richard Biener from comment #3)
> We don't have cross-compilers.

That's exactly the problem here.

(In reply to Michal Suchanek from comment #5)
> (In reply to Richard Biener from comment #3)
> > We don't have cross-compilers.
> 
> That's exactly the problem here.

But that's not a bug but a missing feature...

I don't know what you call those

aarch64-suse-linux-gcc

and similar.

They are crosscompilers without a libc.

We need libc headers to build mainline kernel.

(In reply to Michal Suchanek from comment #7)
> I don't know what you call those
> 
> aarch64-suse-linux-gcc
> 
> and similar.

Oh, indeed, these packages are now part of Tumbleweed:

https://build.opensuse.org/package/show/openSUSE:Factory/cross-aarch64-gcc8
...

Then the bug report is valid; sorry for the noise.

(In reply to Michal Suchanek from comment #7)
> I don't know what you call those
> 
> aarch64-suse-linux-gcc
> 
> and similar.

Those are a convenience provided to you kernel folks who requested
they'd be available without the hassle to untar an icecream environment.

> They are crosscompilers without a libc.
> 
> We need libc headers to build mainline kernel.

Seems to be a new thing.  In theory extending the "hack" to libc (headers)
is possible by re-packaging the native glibc into a noarch cross-%arch-glibc
package and build depending on that.  But this seemed to gross for me.

I also don't really have time to explore this route again (did once during
a hackweek).

(In reply to Petr Tesařík from comment #8)
> (In reply to Michal Suchanek from comment #7)
> > I don't know what you call those
> > 
> > aarch64-suse-linux-gcc
> > 
> > and similar.
> 
> Oh, indeed, these packages are now part of Tumbleweed:
> 
> https://build.opensuse.org/package/show/openSUSE:Factory/cross-aarch64-gcc8
> ...
> 
> Then the bug report is valid; sorry for the noise.

Those are likely not the same as those in Kernel:tools if that provides
libc headers in some way.

However, there is no bug in the compiler itself or in the toolchain - if you provide all necessary files (like header files etc.), they work flawlessly.

It's a missing cross-arch libc, and I'm afraid that qualifies as a feature.

Created attachment 800834 [details]
cross-glibc package

So if you are interested here's the directory containing this kind of cross
glibc "packaging" that I have lying around.

(In reply to Richard Biener from comment #12)
> Created attachment 800834 [details]
> cross-glibc package
> 
> So if you are interested here's the directory containing this kind of cross
> glibc "packaging" that I have lying around.

Oh, it's actually in devel:gcc, just disabled.  And it didn't use noarch
but specific archs and aggregates to copy over.  Making it noarch might
"solve" the need for aggregates.

Linux upstream sort of solved this with dummy-tools.

We now have cross-glibc for a select set of architectures (aarch64 and riscv).