Paul Eggert <egg...@cs.ucla.edu> writes: > On 2023-06-03 06:54, Mike Gilbert wrote: >> In this case, headers from linux-6.1 are being used at build time. >> However, the code is being run on a linux-4.19 kernel. > > Gnulib doesn't support that. If you build with headers from a > particular version of the operating system, you can't necessarily run > on older versions. The reasons for this sort of restriction should be > obvious. >
This is a principle that other core parts of userland have no issue with. For example, util-linux has various fallbacks based on the *runtime* kernel version. This doesn't square with reality, anyway: if I install linux-6.1 and its headers, then I downgrade, I need to then rebuild every piece of the userland I built against the new headers. Tracking that as a user is nontrivial. > If Gentoo builds are regularly targeting older kernels or libraries > than the platform they are building on, then surely that's a problem > in general, not just here. Now, continuing from what I said above, it's not feasible to *require* users to use a kernel from the package manager. Not only do users want to be able to run their own kernel (sometimes even just for a quick test), but this is completely incompatible with having multiple kernels installed in parallel, as you can't have multiple versions of the same linux-headers in /usr/include. Going further: are we really suggesting that someone who was using say, Linux 6.1 for a few days, then downgrades to Linux 5.15 to test something is in an unsupported configuration? This isn't a practical position to have. This assumption *barely* holds for binary distributions where you "upgrade the world" all at once, and as I said, it's questionable there. And it's completely incompatible with source-based distributions. > > I'll cc this to bug-gnulib to give them a heads-up about the > issue. For gnulib readers, the original bug report is here: > > https://bugs.gnu.org/63850
signature.asc
Description: PGP signature