rpms/findutils
7
0
Fork 0
Code Issues Pull Requests Releases Activity

make findutils build on 32bit x86

Browse Source
This commit is contained in:
Kamil Dudka 2022-01-24 10:33:46 +01:00
parent 946c1c1661
commit 7222ae6493
2 changed files with 521 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

514
findutils-4.8.0-gnulib-time_t.patch Normal file
View File

@ -0,0 +1,514 @@
From 67c20bbc7030d162132b7f7c7fbefbf95fc2bc76 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 1 Jul 2021 19:29:57 -0700
Subject: [PATCH 1/5] year2038: support glibc 2.34 _TIME_BITS=64
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit,
defining _FILE_OFFSET_BITS=64 and _TIME_BITS=64 makes time_t 64-bit.
Apps must define both macros. Gnulib applications that use either
the largefile or the year2038 modules will want this behavior;
largefile because it deals with the off_t and ino_t components of
struct stat already, and so should also deal with time_t.
* m4/largefile.m4: Override two macros even in Autoconf 2.70 and later.
(_AC_SYS_LARGEFILE_MACRO_VALUE): #undef $1 before #defining it, in
case some other Gnulib macro has #defined it.
(AC_SYS_LARGEFILE): Use AS_IF and AS_CASE to propagate AC_REQUIREs.
Invoke gl_YEAR2038_BODY if we need to set _FILE_OFFSET_BITS=64.
* m4/year2038.m4 (gl_YEAR2038_TEST_INCLUDES): New macro.
(gl_YEAR2038_BODY): New macro, with gl_YEAR2038’s old body; this
macro is designed to be used directly instead of being
AC_REQUIREd. It takes an argument specifying whether 64-bit is
required. Set _TIME_BITS=64 if this makes a difference in time_t
width when setting _FILE_OFFSET_BITS=64. Do not warn about
32-bit time_t more than once.
* modules/largefile (Files): Add year2038.m4.
(Depends-on): Require gl_YEAR2038_EARLY.
Upstream-commit: dc09dc0888485698a8e74205b9df43159aef0f61
Signed-off-by: Kamil Dudka <kdudka@redhat.com>
---
gl/m4/largefile.m4 | 28 +++++++++++----------
gl/m4/year2038.m4 | 63 ++++++++++++++++++++++++++++++++++++----------
2 files changed, 65 insertions(+), 26 deletions(-)
diff --git a/gl/m4/largefile.m4 b/gl/m4/largefile.m4
index cadb16d..172a4da 100644
--- a/gl/m4/largefile.m4
+++ b/gl/m4/largefile.m4
@@ -22,7 +22,8 @@ AC_DEFUN([gl_SET_LARGEFILE_SOURCE],
esac
])
-# The following implementation works around a problem in autoconf <= 2.69;
+# Work around a problem in Autoconf through at least 2.71 on glibc 2.34+
+# with _TIME_BITS. Also, work around a problem in autoconf <= 2.69:
# AC_SYS_LARGEFILE does not configure for large inodes on Mac OS X 10.5,
# or configures them incorrectly in some cases.
m4_version_prereq([2.70], [], [
@@ -40,6 +41,7 @@ m4_define([_AC_SYS_LARGEFILE_TEST_INCLUDES],
&& LARGE_OFF_T % 2147483647 == 1)
? 1 : -1]];[]dnl
])
+])# m4_version_prereq 2.70
# _AC_SYS_LARGEFILE_MACRO_VALUE(C-MACRO, VALUE,
@@ -54,7 +56,8 @@ m4_define([_AC_SYS_LARGEFILE_MACRO_VALUE],
[AC_LANG_PROGRAM([$5], [$6])],
[$3=no; break])
m4_ifval([$6], [AC_LINK_IFELSE], [AC_COMPILE_IFELSE])(
- [AC_LANG_PROGRAM([#define $1 $2
+ [AC_LANG_PROGRAM([#undef $1
+#define $1 $2
$5], [$6])],
[$3=$2; break])
$3=unknown
@@ -80,9 +83,8 @@ rm -rf conftest*[]dnl
AC_DEFUN([AC_SYS_LARGEFILE],
[AC_ARG_ENABLE(largefile,
[ --disable-largefile omit support for large files])
-if test "$enable_largefile" != no; then
-
- AC_CACHE_CHECK([for special C compiler options needed for large files],
+AS_IF([test "$enable_largefile" != no],
+ [AC_CACHE_CHECK([for special C compiler options needed for large files],
ac_cv_sys_largefile_CC,
[ac_cv_sys_largefile_CC=no
if test "$GCC" != yes; then
@@ -107,15 +109,15 @@ if test "$enable_largefile" != no; then
ac_cv_sys_file_offset_bits,
[Number of bits in a file offset, on hosts where this is settable.],
[_AC_SYS_LARGEFILE_TEST_INCLUDES])
- if test $ac_cv_sys_file_offset_bits = unknown; then
- _AC_SYS_LARGEFILE_MACRO_VALUE(_LARGE_FILES, 1,
- ac_cv_sys_large_files,
- [Define for large files, on AIX-style hosts.],
- [_AC_SYS_LARGEFILE_TEST_INCLUDES])
- fi
-fi
+ AS_CASE([$ac_cv_sys_file_offset_bits],
+ [unknown],
+ [_AC_SYS_LARGEFILE_MACRO_VALUE([_LARGE_FILES], [1],
+ [ac_cv_sys_large_files],
+ [Define for large files, on AIX-style hosts.],
+ [_AC_SYS_LARGEFILE_TEST_INCLUDES])],
+ [64],
+ [gl_YEAR2038_BODY([false])])])
])# AC_SYS_LARGEFILE
-])# m4_version_prereq 2.70
# Enable large files on systems where this is implemented by Gnulib, not by the
# system headers.
diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4
index 2534622..635ef12 100644
--- a/gl/m4/year2038.m4
+++ b/gl/m4/year2038.m4
@@ -1,4 +1,4 @@
-# year2038.m4 serial 3
+# year2038.m4 serial 4
dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -18,13 +18,29 @@ AC_DEFUN([gl_YEAR2038_EARLY],
esac
])
-AC_DEFUN([gl_YEAR2038],
+# gl_YEAR2038_TEST_INCLUDES
+# -------------------------
+AC_DEFUN([gl_YEAR2038_TEST_INCLUDES],
+[[
+ #include <time.h>
+ /* Check that time_t can represent 2**63 - 1 correctly.
+ We can't simply define LARGE_TIME_T to be 9223372036854775807,
+ since some C++ compilers masquerading as C compilers
+ incorrectly reject 9223372036854775807. */
+ #define LARGE_TIME_T (((time_t) 1 << 31 << 31) - 1 + ((time_t) 1 << 31 << 31))
+ int verify_time_t_range[(LARGE_TIME_T % 2147483629 == 721
+ && LARGE_TIME_T % 2147483647 == 1)
+ ? 1 : -1];
+]])
+
+# gl_YEAR2038_BODY(REQUIRE-64-BIT)
+----------------------------------
+AC_DEFUN([gl_YEAR2038_BODY],
[
dnl On many systems, time_t is already a 64-bit type.
dnl On those systems where time_t is still 32-bit, it requires kernel
- dnl and libc support to make it 64-bit. For glibc on Linux/x86, this
- dnl is work in progress; see
- dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
+ dnl and libc support to make it 64-bit. For glibc 2.34 and later on Linux,
+ dnl defining _TIME_BITS=64 and _FILE_OFFSET_BITS=64 is needed on x86 and ARM.
dnl
dnl On native Windows, the system include files define types __time32_t
dnl and __time64_t. By default, time_t is an alias of
@@ -36,13 +52,28 @@ AC_DEFUN([gl_YEAR2038],
dnl __time32_t.
AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64],
[AC_COMPILE_IFELSE(
- [AC_LANG_PROGRAM(
- [[#include <time.h>
- int verify_time_t_size[sizeof (time_t) >= 8 ? 1 : -1];
- ]],
- [[]])],
+ [AC_LANG_SOURCE([gl_YEAR2038_TEST_INCLUDES])],
[gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
])
+ if test "$gl_cv_type_time_t_64" = no; then
+ AC_CACHE_CHECK([for 64-bit time_t with _TIME_BITS=64],
+ [gl_cv_type_time_t_bits_macro],
+ [AC_COMPILE_IFELSE(
+ [AC_LANG_SOURCE([[#define _TIME_BITS 64
+ #define _FILE_OFFSET_BITS 64
+ ]gl_YEAR2038_TEST_INCLUDES])],
+ [gl_cv_type_time_t_bits_macro=yes],
+ [gl_cv_type_time_t_bits_macro=no])
+ ])
+ if test "$gl_cv_type_time_t_bits_macro" = yes; then
+ AC_DEFINE([_TIME_BITS], [64],
+ [Number of bits in a timestamp, on hosts where this is settable.])
+ dnl AC_SYS_LARGFILE also defines this; it's OK if we do too.
+ AC_DEFINE([_FILE_OFFSET_BITS], [64],
+ [Number of bits in a file offset, on hosts where this is settable.])
+ gl_cv_type_time_t_64=yes
+ fi
+ fi
if test $gl_cv_type_time_t_64 = no; then
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE(
@@ -53,18 +84,24 @@ AC_DEFUN([gl_YEAR2038],
#endif
]])],
[AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
- [# If TIME_T_32_BIT_OK is "no" (the default) and not cross-compiling
+ [# If not cross-compiling and $1 says we should check,
# and 'touch' works with a large timestamp, then evidently 64-bit time_t
# is desired and supported, so fail and ask the builder to fix the
# problem. Otherwise, just warn the builder.
- if test "${TIME_T_32_BIT_OK-no}" = no \
+ if $1 \
&& test $cross_compiling = no \
&& TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
rm -f conftest.time
AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.])
- else
+ elif test "$gl_warned_about_64_bit_time_t" != yes; then
AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
+ gl_warned_about_64_bit_time_t=yes
fi
])
fi
])
+
+AC_DEFUN([gl_YEAR2038],
+[
+ gl_YEAR2038_BODY([test "${TIME_T_32_BIT_OK-no}" = no])
+])
--
2.31.1
From 6df0907c00ee44cb36a7caa118d1a6492e0056e6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 6 Jul 2021 15:21:44 -0700
Subject: [PATCH 2/5] year2038: Add --disable-year2038 option
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Also, document this stuff better. Suggested by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2021-07/msg00011.html
* m4/year2038.m4 (gl_YEAR2038_BODY): Support ‘./configure
--disable-year2038’ to disable 64-bit time_t when that is not the
default. Arg is now either empty or nonempty (not a shell
command) and is evaluated at m4 expansion time instead of at
runtime; all callers changed.
Upstream-commit: 7dd2562058aa4cc3a1a4714b6248193fd5444491
Signed-off-by: Kamil Dudka <kdudka@redhat.com>
---
gl/m4/year2038.m4 | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4
index 635ef12..ad7f303 100644
--- a/gl/m4/year2038.m4
+++ b/gl/m4/year2038.m4
@@ -1,4 +1,4 @@
-# year2038.m4 serial 4
+# year2038.m4 serial 5
dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -37,6 +37,10 @@ AC_DEFUN([gl_YEAR2038_TEST_INCLUDES],
----------------------------------
AC_DEFUN([gl_YEAR2038_BODY],
[
+ AC_ARG_ENABLE([year2038],
+ [ --disable-year2038 omit support for timestamps past the year 2038])
+ AS_IF([test "$enable_year2038" != no],
+ [
dnl On many systems, time_t is already a 64-bit type.
dnl On those systems where time_t is still 32-bit, it requires kernel
dnl and libc support to make it 64-bit. For glibc 2.34 and later on Linux,
@@ -88,20 +92,21 @@ AC_DEFUN([gl_YEAR2038_BODY],
# and 'touch' works with a large timestamp, then evidently 64-bit time_t
# is desired and supported, so fail and ask the builder to fix the
# problem. Otherwise, just warn the builder.
- if $1 \
- && test $cross_compiling = no \
- && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
- rm -f conftest.time
- AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.])
- elif test "$gl_warned_about_64_bit_time_t" != yes; then
+ m4_ifval([$1],
+ [if test $cross_compiling = no \
+ && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
+ rm -f conftest.time
+ AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with '--disable-year2038'.])
+ fi])
+ if test "$gl_warned_about_64_bit_time_t" != yes; then
AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
gl_warned_about_64_bit_time_t=yes
fi
])
- fi
+ fi])
])
AC_DEFUN([gl_YEAR2038],
[
- gl_YEAR2038_BODY([test "${TIME_T_32_BIT_OK-no}" = no])
+ gl_YEAR2038_BODY([require-64-bit])
])
--
2.31.1
From 49816ad1b32b1f210841ac44cb64fa68da56806f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 2 Aug 2021 09:30:50 -0700
Subject: [PATCH 3/5] year2038: port to unusual time_t platforms
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* m4/year2038.m4 (gl_YEAR2038_TEST_INCLUDES): Check that time_t
can go to 2**32 - 1, not to 2**63 - 1, as the former is enough to
be year 2038 safe. Unsigned 32-bit time_t (AmigaOS) and signed
40-bit time_t (Unisys ClearPath) have occurred in the wild, and
even if Gnulib code is rarely or never ported to them there’s no
need to exclude them merely because of year 2038 issues.
(gl_YEAR2038_BODY): Adjust messages to match. Use 2**32 - 1,
not 2**32, as the test timestamp, to allow unsigned 32-bit time_t.
Upstream-commit: 784f55e5c59abde4eabf4e08169d1c50363280b4
Signed-off-by: Kamil Dudka <kdudka@redhat.com>
---
gl/m4/year2038.m4 | 61 ++++++++++++++++++++++++++++-------------------
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4
index ad7f303..7ae004e 100644
--- a/gl/m4/year2038.m4
+++ b/gl/m4/year2038.m4
@@ -1,11 +1,11 @@
-# year2038.m4 serial 5
+# year2038.m4 serial 6
dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
dnl with or without modifications, as long as this notice is preserved.
-dnl Attempt to ensure that 'time_t' is a 64-bit type
-dnl and that the functions time(), stat(), etc. return 64-bit times.
+dnl Attempt to ensure that 'time_t' can go past the year 2038 and that
+dnl the functions 'time', 'stat', etc. work with post-2038 timestamps.
AC_DEFUN([gl_YEAR2038_EARLY],
[
@@ -23,18 +23,15 @@ AC_DEFUN([gl_YEAR2038_EARLY],
AC_DEFUN([gl_YEAR2038_TEST_INCLUDES],
[[
#include <time.h>
- /* Check that time_t can represent 2**63 - 1 correctly.
- We can't simply define LARGE_TIME_T to be 9223372036854775807,
- since some C++ compilers masquerading as C compilers
- incorrectly reject 9223372036854775807. */
- #define LARGE_TIME_T (((time_t) 1 << 31 << 31) - 1 + ((time_t) 1 << 31 << 31))
- int verify_time_t_range[(LARGE_TIME_T % 2147483629 == 721
- && LARGE_TIME_T % 2147483647 == 1)
+ /* Check that time_t can represent 2**32 - 1 correctly. */
+ #define LARGE_TIME_T (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30))
+ int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535
+ && LARGE_TIME_T % 65537 == 0)
? 1 : -1];
]])
-# gl_YEAR2038_BODY(REQUIRE-64-BIT)
-----------------------------------
+# gl_YEAR2038_BODY(REQUIRE-YEAR2038-SAFE)
+-----------------------------------------
AC_DEFUN([gl_YEAR2038_BODY],
[
AC_ARG_ENABLE([year2038],
@@ -54,12 +51,12 @@ AC_DEFUN([gl_YEAR2038_BODY],
dnl alias of __time64_t.
dnl And when compiling with -D_USE_32BIT_TIME_T, time_t is an alias of
dnl __time32_t.
- AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64],
+ AC_CACHE_CHECK([for time_t past the year 2038], [gl_cv_type_time_t_y2038],
[AC_COMPILE_IFELSE(
[AC_LANG_SOURCE([gl_YEAR2038_TEST_INCLUDES])],
- [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
+ [gl_cv_type_time_t_y2038=yes], [gl_cv_type_time_t_y2038=no])
])
- if test "$gl_cv_type_time_t_64" = no; then
+ if test "$gl_cv_type_time_t_y2038" = no; then
AC_CACHE_CHECK([for 64-bit time_t with _TIME_BITS=64],
[gl_cv_type_time_t_bits_macro],
[AC_COMPILE_IFELSE(
@@ -75,10 +72,10 @@ AC_DEFUN([gl_YEAR2038_BODY],
dnl AC_SYS_LARGFILE also defines this; it's OK if we do too.
AC_DEFINE([_FILE_OFFSET_BITS], [64],
[Number of bits in a file offset, on hosts where this is settable.])
- gl_cv_type_time_t_64=yes
+ gl_cv_type_time_t_y2038=yes
fi
fi
- if test $gl_cv_type_time_t_64 = no; then
+ if test $gl_cv_type_time_t_y2038 = no; then
AC_COMPILE_IFELSE(
[AC_LANG_SOURCE(
[[#ifdef _USE_32BIT_TIME_T
@@ -87,20 +84,34 @@ AC_DEFUN([gl_YEAR2038_BODY],
error fail
#endif
]])],
- [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
+ [AC_MSG_FAILURE(
+ [The 'time_t' type stops working after January 2038.
+ Remove _USE_32BIT_TIME_T from the compiler flags.])],
[# If not cross-compiling and $1 says we should check,
- # and 'touch' works with a large timestamp, then evidently 64-bit time_t
+ # and 'touch' works with a large timestamp, then evidently wider time_t
# is desired and supported, so fail and ask the builder to fix the
# problem. Otherwise, just warn the builder.
m4_ifval([$1],
[if test $cross_compiling = no \
- && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
+ && TZ=UTC0 touch -t 210602070628.15 conftest.time 2>/dev/null; then
+ case `TZ=UTC0 LC_ALL=C ls -l conftest.time 2>/dev/null` in
+ *'Feb 7 2106'* | *'Feb 7 17:10'*)
+ AC_MSG_FAILURE(
+ [The 'time_t' type stops working after January 2038,
+ and your system appears to support a wider 'time_t'.
+ Try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'.
+ To build with a 32-bit time_t anyway (not recommended),
+ configure with '--disable-year2038'.]);;
+ esac
rm -f conftest.time
- AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with '--disable-year2038'.])
fi])
- if test "$gl_warned_about_64_bit_time_t" != yes; then
- AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
- gl_warned_about_64_bit_time_t=yes
+ if test "$gl_warned_about_y2038" != yes; then
+ AC_MSG_WARN(
+ [The 'time_t' type stops working after January 2038,
+ and this package needs a wider 'time_t' type
+ if there is any way to access timestamps after that.
+ Configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"' perhaps?])
+ gl_warned_about_y2038=yes
fi
])
fi])
@@ -108,5 +119,5 @@ AC_DEFUN([gl_YEAR2038_BODY],
AC_DEFUN([gl_YEAR2038],
[
- gl_YEAR2038_BODY([require-64-bit])
+ gl_YEAR2038_BODY([require-year2038-safe])
])
--
2.31.1
From cd11a3e21d4aba6a8655a25bc0299cf4a72f58f5 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 2 Aug 2021 09:44:59 -0700
Subject: [PATCH 4/5] year2038: work even if time_t is narrower than int
Upstream-commit: 7c6538cf0584a5ad3e2e46f64b1936eea4cddecc
Signed-off-by: Kamil Dudka <kdudka@redhat.com>
---
gl/m4/year2038.m4 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4
index 7ae004e..f53b03f 100644
--- a/gl/m4/year2038.m4
+++ b/gl/m4/year2038.m4
@@ -24,7 +24,8 @@ AC_DEFUN([gl_YEAR2038_TEST_INCLUDES],
[[
#include <time.h>
/* Check that time_t can represent 2**32 - 1 correctly. */
- #define LARGE_TIME_T (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30))
+ #define LARGE_TIME_T \\
+ ((time_t) (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)))
int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535
&& LARGE_TIME_T % 65537 == 0)
? 1 : -1];
--
2.31.1
From 1e2e81f10204a4d176c8ec14bd95b9aa43d9012c Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Sat, 7 Aug 2021 16:03:22 +0200
Subject: [PATCH 5/5] year2038: Fix recommendation regarding -m64 flag.
* m4/year2038.m4 (gl_YEAR2038_BODY): Recommend to put option --m64 in
CC, not in CPPFLAGS and LDFLAGS.
Upstream-commit: edb4fbdc959660ef753bdc684aaf14b555871a2a
Signed-off-by: Kamil Dudka <kdudka@redhat.com>
---
gl/m4/year2038.m4 | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4
index f53b03f..da0f8d7 100644
--- a/gl/m4/year2038.m4
+++ b/gl/m4/year2038.m4
@@ -1,4 +1,4 @@
-# year2038.m4 serial 6
+# year2038.m4 serial 7
dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -100,7 +100,7 @@ AC_DEFUN([gl_YEAR2038_BODY],
AC_MSG_FAILURE(
[The 'time_t' type stops working after January 2038,
and your system appears to support a wider 'time_t'.
- Try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'.
+ Try configuring with 'CC="${CC} -m64"'.
To build with a 32-bit time_t anyway (not recommended),
configure with '--disable-year2038'.]);;
esac
@@ -111,7 +111,7 @@ AC_DEFUN([gl_YEAR2038_BODY],
[The 'time_t' type stops working after January 2038,
and this package needs a wider 'time_t' type
if there is any way to access timestamps after that.
- Configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"' perhaps?])
+ Configure with 'CC="${CC} -m64"' perhaps?])
gl_warned_about_y2038=yes
fi
])
--
2.31.1

8
findutils.spec
View File

@ -1,12 +1,15 @@
Summary: The GNU versions of find utilities (find and xargs) Summary: The GNU versions of find utilities (find and xargs)
Name: findutils Name: findutils
Version: 4.8.0 Version: 4.8.0
Release: 5%{?dist} Release: 6%{?dist}
Epoch: 1 Epoch: 1
License: GPLv3+ License: GPLv3+
URL: https://www.gnu.org/software/findutils/ URL: https://www.gnu.org/software/findutils/
Source0: https://ftp.gnu.org/pub/gnu/%{name}/%{name}-%{version}.tar.xz Source0: https://ftp.gnu.org/pub/gnu/%{name}/%{name}-%{version}.tar.xz
# make findutils build on 32bit x86
Patch0: findutils-4.8.0-gnulib-time_t.patch
# do not build locate # do not build locate
Patch1: findutils-4.5.15-no-locate.patch Patch1: findutils-4.5.15-no-locate.patch
@ -111,6 +114,9 @@ rm -f %{buildroot}%{_infodir}/dir
%{_infodir}/find-maint.info.* %{_infodir}/find-maint.info.*
%changelog %changelog
* Mon Jan 24 2022 Kamil Dudka <kdudka@redhat.com> - 1:4.8.0-6
- make findutils build on 32bit x86
* Thu Jan 20 2022 Fedora Release Engineering <releng@fedoraproject.org> - 1:4.8.0-5 * Thu Jan 20 2022 Fedora Release Engineering <releng@fedoraproject.org> - 1:4.8.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild