bug#63850: cp fails for files > 2 GB if copy offload is unsupported

[Paul Eggert]

On 2023-06-06 03:02, Sam James wrote:
> Thanks Paul. Do you know if there's any other cases of this in gnulib?

There's no other use of linux/version.h in Gnulib. However, this doesn't 
mean there are no other instances of the problem, as it's common to 
assume that you'll run on a host no older than the build host. Every use 
of Autoconf macros like AC_RUN_IFELSE assume this sort of thing, and I 
would not be surprised if there are other examples of this more-general 
problem when some builders (unwisely) build apps intended to run on 
platforms older than the build platform. (For what it's worth, I count 
331 uses of AC_RUN_IFELSE in Gnulib; it'd be a pain to audit them all.)

It's OK to build glibc for Linux kernels somewhat older than the build 
kernel, since glibc explicitly exports that. But it's not OK to build 
other packages that way, since they don't support it. You'll get away 
with it in many cases, but when it doesn't work then the problem is on 
the builder, not on the packages being built.


> (or whether, by chance, if you know off the top of your head if any
> other gnulib consumers definitely use copy_file_range?)

Other coreutils programs like 'install' use copy_file_range.

Emacs uses it. I just now installed the following patch into 
bleeding-edge Emacs to work around the problem, by updating to current 
Gnulib. This workaround should appear in Emacs 30, whenever that happens 
(not for a year or two I'd think, as Emacs 29 isn't out yet).

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a902156068ab071f93cc9bbd34cd320919b74064

PS. I'm boldly marking the coreutils bug as fixed.