Bug 1127188 - cannot update kernel configuration with cross-compiler
cannot update kernel configuration with cross-compiler
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Richard Biener
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-27 12:18 UTC by Michal Suchanek
Modified: 2022-07-21 17:27 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
cross-glibc package (2.94 KB, application/gzip)
2019-03-21 14:20 UTC, Richard Biener
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Suchanek 2019-02-27 12:18:36 UTC
SUSE cross-compilers do not include libc. Some kernel configuration options depend on compiler features including the ability to link userspace binaries. This differs between native compilers and cross-compilers causing different configuration to be generated. The kernel build fails when the configuration changes.
Comment 1 Jiri Slaby 2019-03-01 06:21:53 UTC
Please attach some example.

I am not the right person to be assigned here, so resetting.
Comment 2 Michal Suchanek 2019-03-01 09:11:13 UTC
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.
Comment 3 Richard Biener 2019-03-21 09:10:25 UTC
We don't have cross-compilers.
Comment 4 Petr Tesařík 2019-03-21 09:55:46 UTC
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.
Comment 5 Michal Suchanek 2019-03-21 12:18:58 UTC
(In reply to Richard Biener from comment #3)
> We don't have cross-compilers.

That's exactly the problem here.
Comment 6 Richard Biener 2019-03-21 12:25:44 UTC
(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...
Comment 7 Michal Suchanek 2019-03-21 12:43:38 UTC
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.
Comment 8 Petr Tesařík 2019-03-21 12:55:50 UTC
(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.
Comment 9 Richard Biener 2019-03-21 12:57:37 UTC
(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).
Comment 10 Richard Biener 2019-03-21 12:58:38 UTC
(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.
Comment 11 Petr Tesařík 2019-03-21 12:59:43 UTC
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.
Comment 12 Richard Biener 2019-03-21 14:20:06 UTC
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.
Comment 13 Richard Biener 2019-03-21 14:21:49 UTC
(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.
Comment 17 Michal Suchanek 2021-09-13 12:51:59 UTC
Linux upstream sort of solved this with dummy-tools.
Comment 18 Richard Biener 2022-03-22 13:04:05 UTC
We now have cross-glibc for a select set of architectures (aarch64 and riscv).