[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63850: cp fails for files > 2 GB if copy offload is unsupported
From: |
Sam James |
Subject: |
bug#63850: cp fails for files > 2 GB if copy offload is unsupported |
Date: |
Tue, 06 Jun 2023 06:09:16 +0100 |
User-agent: |
mu4e 1.10.3; emacs 29.0.91 |
Paul Eggert <eggert@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
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Sam James, 2023/06/02
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Pádraig Brady, 2023/06/02
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/03
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Mike Gilbert, 2023/06/03
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Arsen Arsenović, 2023/06/03
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported,
Sam James <=
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Sam James, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Pádraig Brady, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Sam James, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Pádraig Brady, 2023/06/06
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/07
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Sam James, 2023/06/07
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/07
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Arsen Arsenović, 2023/06/08
- bug#63850: cp fails for files > 2 GB if copy offload is unsupported, Paul Eggert, 2023/06/08