If we really need to cater to the practice of building for an older
system than the build host (which to my mind is asking for trouble),
then instead of having Gnulib try to work around the bugs in
copy_file_range in Linux kernels before 5.3, it should simply not use
copy_file_range in these older kernels.
In other words, something like the attached patch should be more
reliable than the other band-aids proposed.From 87b95c17dc8611f9483b966d052eefc930f43927 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Mon, 5 Jun 2023 22:04:37 -0700
Subject: [PATCH] copy-file-range: support building for older kernels
* m4/copy-file-range.m4 (gl_FUNC_COPY_FILE_RANGE):
Remove static check, to support the dubious practice of
building for platforms that predate the build platform.
On working kernels this adds an extra syscall the first time
that copy_file_range is used. Problem reported for Gentoo by
Sam James <https://bugs.gnu.org/63850>.
---
ChangeLog | 8 ++++++++
m4/copy-file-range.m4 | 18 +++---------------
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d8f04f737d..a917eb63a6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2023-06-05 Paul Eggert <egg...@cs.ucla.edu>
+ copy-file-range: support building for older kernels
+ * m4/copy-file-range.m4 (gl_FUNC_COPY_FILE_RANGE):
+ Remove static check, to support the dubious practice of
+ building for platforms that predate the build platform.
+ On working kernels this adds an extra syscall the first time
+ that copy_file_range is used. Problem reported for Gentoo by
+ Sam James <https://bugs.gnu.org/63850>.
+
manywarnings: more nuance about optimization
* doc/manywarnings.texi (manywarnings): Suggest compiling with the
optimization flags commonly used, as opposed to -O2 and -O0
diff --git a/m4/copy-file-range.m4 b/m4/copy-file-range.m4
index d41f2c4831..fa6ab34109 100644
--- a/m4/copy-file-range.m4
+++ b/m4/copy-file-range.m4
@@ -39,21 +39,9 @@ AC_DEFUN([gl_FUNC_COPY_FILE_RANGE],
case $host_os in
linux*)
- AC_CACHE_CHECK([whether copy_file_range is known to work],
- [gl_cv_copy_file_range_known_to_work],
- [AC_COMPILE_IFELSE(
- [AC_LANG_PROGRAM(
- [[#include <linux/version.h>
- ]],
- [[#if LINUX_VERSION_CODE < KERNEL_VERSION (5, 3, 0)
- #error "copy_file_range is buggy"
- #endif
- ]])],
- [gl_cv_copy_file_range_known_to_work=yes],
- [gl_cv_copy_file_range_known_to_work=no])])
- if test "$gl_cv_copy_file_range_known_to_work" = no; then
- REPLACE_COPY_FILE_RANGE=1
- fi;;
+ # See copy-file-range.c comment re pre-5.3 Linux kernel bugs.
+ # We should be able to remove this hack in 2025.
+ REPLACE_COPY_FILE_RANGE=1;;
esac
fi
])
--
2.39.2
