GNU bug report logs -
#63850
cp fails for files > 2 GB if copy offload is unsupported
Previous Next
Reported by: Sam James <sam <at> gentoo.org>
Date: Fri, 2 Jun 2023 15:50:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
Full log
Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sam James <sam <at> gentoo.org> writes:
> [[PGP Signed Part:Undecided]]
>
> Paul Eggert <eggert <at> 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.
Just to be clear: I totally agree this isn't feasible for general
libraries (and their headers). It's just that linux-headers is
a special case, because you can't easily juggle different versions of
it, and it's expected that users may vary their kernel version.
Also, glibc says the latest should always be fine:
https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F.
Of course, gnulib isn't glibc, but I'm pointing out that this is
established practice.
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 2 years and 41 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.