distributions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: "Bruno Haible" <bruno@clisp.org>,
	"Zack Weinberg" <zack@owlfolio.org>,
	"Pádraig Brady" <P@draigbrady.com>,
	bug-gnulib@gnu.org
Cc: Sam James <sam@gentoo.org>, distributions@lists.linux.dev
Subject: Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Date: Mon, 10 Apr 2023 16:00:26 -0700	[thread overview]
Message-ID: <7fb8ec1e-0db9-dd86-d718-214133f88b53@cs.ucla.edu> (raw)
In-Reply-To: <9797572.lZ1qq7WqSs@nimes>

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

On 2023-04-10 15:36, Bruno Haible wrote:
> I like this. Thanks.

OK, then let's hear Zack's opinion and hopefully move forward.

In the meantime I installed the attached Gnulib patch, which documents 
the current situation better as you suggested (e.g., by suggesting 
year2038 first) and updates some of the version info.

[-- Attachment #2: 0001-doc-document-year2038-first.patch --]
[-- Type: text/x-patch, Size: 5152 bytes --]

From 3e6b572b5f6dcd204f3636e3c7a265063a315f2c Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 10 Apr 2023 15:15:37 -0700
Subject: [PATCH 1/3] doc: document year2038 first

* doc/year2038.texi: Document year2038 first, then
year2038-required.
---
 doc/posix-headers/time.texi |  2 +-
 doc/year2038.texi           | 59 +++++++++++++++++++++----------------
 2 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/doc/posix-headers/time.texi b/doc/posix-headers/time.texi
index f9d1def2aa..70814d6cda 100644
--- a/doc/posix-headers/time.texi
+++ b/doc/posix-headers/time.texi
@@ -19,7 +19,7 @@ NetBSD 5.0.
 @end itemize
 
 Portability problems fixed by the Gnulib module
-@code{year2038-required} or @code{year2038}:
+@code{year2038} or @code{year2038-required}:
 @itemize
 @item
 On some platforms where @code{time_t} defaults to 32-bit but can be
diff --git a/doc/year2038.texi b/doc/year2038.texi
index cae738c5da..81b212e455 100644
--- a/doc/year2038.texi
+++ b/doc/year2038.texi
@@ -8,15 +8,39 @@ after 2038-01-19 03:14:08 UTC@.  See
 @url{https://en.wikipedia.org/wiki/Year_2038_problem, Year 2038
 problem} for details.
 
-The Gnulib module @samp{year2038-required} fixes this problem, by
-making @code{time_t} wide enough to represent timestamps after 2038.
-This has no effect on most current systems, which have timestamps that
-are already wide enough.  However, @samp{year2038-required} arranges
-for builds on legacy 32-bit x86 and ARM Linux kernels running glibc
-2.34 and later to compile with @samp{_TIME_BITS=64} to get wider
+The Gnulib module @samp{year2038} fixes this problem on some
+platforms, by making @code{time_t} wide enough to represent timestamps
+after 2038.  This has no effect on most current platforms, which have
+timestamps that are already wide enough.  However, @samp{year2038} by
+default arranges for builds on legacy 32-bit Linux kernels running
+glibc 2.34 and later to compile with @samp{_TIME_BITS=64} to get wider
 timestamps.  On older platforms that do not support timestamps after
-the year 2038, @samp{year2038-required} causes @command{configure} to
-fail.
+the year 2038, @samp{year2038} causes @command{configure} to issue a
+warning but still proceed.  On platforms that appear to support
+post-2038 timestamps but where something prevents this from working,
+@command{configure} fails.
+
+The default behavior of @samp{year2038} can be overridden by using the
+@command{configure} option @option{--disable-year2038}, which
+suppresses support for post-2038 timestamps.  This may be useful if
+the package links to other libraries whose user-facing ABIs still
+require @code{time_t} to be 32-bit on your platform.
+
+The Gnulib module @samp{year2038-required} is like @samp{year2038},
+except it rejects platforms where @code{time_t} cannot represent
+timestamps after 2038, and it lacks a @option{--disable-year2038}
+option.  If this module is used and a 32-platform cannot support
+64-bit @code{time_t}, one can still fix the year-2038 problem by using
+a 64-bit instead of a 32-bit build, as noted in the architecture list
+below.  If all else fails one can configure with
+@samp{ac_year2038_required=no}; however, the resulting programs will
+mishandle timestamps after 2038.
+
+The Gnulib module @samp{year2038-required} is
+recommended for packages intended for use on 32-bit platforms
+after the year 2038.  However, if your package needs to support
+32-bit platforms that will not be used after the year 2038,
+you can use the @samp{year2038} module instead.
 
 With the @samp{year2038-required} module, @command{configure} fails
 on the following 32-bit platforms (or ABIs in bi-arch systems):
@@ -65,26 +89,11 @@ FreeBSD/arm,
 Minix 3.3.
 @end itemize
 
-The Gnulib module @samp{year2038} is like @samp{year2038-required},
-except that it causes @command{configure} to fail only when it appears
-that the current system should support post-2038 timestamps but
-something prevents that from working.  Also, @samp{year2038} gives
-@command{configure} a @option{--disable-year2038} option, which
-suppresses support for post-2038 timestamps.  This may be useful if
-the package links to other libraries whose user-facing ABIs still
-require @code{time_t} to be 32-bit on your platform.
-
-The Gnulib module @samp{year2038-required} is
-recommended for any package that might be used after the year 2038 on
-32-bit platforms.  However, if your package needs to support
-platforms that will not be used after the year 2038,
-you can use the @samp{year2038} module instead.
-
 If the Gnulib module @samp{largefile} is used but neither
 @samp{year2038} nor @samp{year2038-required} is used,
 @command{configure} will have an option @option{--enable-year2038}
 that causes @code{configure} to behave as if @samp{year2038} was used.
 This is for packages that have long used @samp{largefile} but have not
-gotten around to upgrade their Gnulib module list to include
-@samp{year2038-required} or @samp{year2038}.
+gotten around to upgrading their Gnulib module list to include
+@samp{year2038} or @samp{year2038-required}.
 @xref{Large File Support}.
-- 
2.37.2


[-- Attachment #3: 0002-doc-moved-year2038-para-up.patch --]
[-- Type: text/x-patch, Size: 1939 bytes --]

From b4c04569ef149bf658dc387b193cef1c8d3aaf0e Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 10 Apr 2023 15:18:19 -0700
Subject: [PATCH 2/3] doc: moved year2038 para up
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/year2038.texi: Move a paragraph up,
as it’s lonely at the end.
---
 doc/year2038.texi | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/doc/year2038.texi b/doc/year2038.texi
index 81b212e455..3d58659a43 100644
--- a/doc/year2038.texi
+++ b/doc/year2038.texi
@@ -42,6 +42,15 @@ after the year 2038.  However, if your package needs to support
 32-bit platforms that will not be used after the year 2038,
 you can use the @samp{year2038} module instead.
 
+If the Gnulib module @samp{largefile} is used but neither
+@samp{year2038} nor @samp{year2038-required} is used,
+@command{configure} will have an option @option{--enable-year2038}
+that causes @code{configure} to behave as if @samp{year2038} was used.
+This is for packages that have long used @samp{largefile} but have not
+gotten around to upgrading their Gnulib module list to include
+@samp{year2038} or @samp{year2038-required}.
+@xref{Large File Support}.
+
 With the @samp{year2038-required} module, @command{configure} fails
 on the following 32-bit platforms (or ABIs in bi-arch systems):
 @itemize
@@ -88,12 +97,3 @@ FreeBSD/arm,
 @item
 Minix 3.3.
 @end itemize
-
-If the Gnulib module @samp{largefile} is used but neither
-@samp{year2038} nor @samp{year2038-required} is used,
-@command{configure} will have an option @option{--enable-year2038}
-that causes @code{configure} to behave as if @samp{year2038} was used.
-This is for packages that have long used @samp{largefile} but have not
-gotten around to upgrading their Gnulib module list to include
-@samp{year2038} or @samp{year2038-required}.
-@xref{Large File Support}.
-- 
2.37.2


[-- Attachment #4: 0003-doc-update-list-of-year2038-platforms.patch --]
[-- Type: text/x-patch, Size: 3035 bytes --]

From be7c3fa0e35b9f11eb3329590426477c6459f7c8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 10 Apr 2023 15:15:37 -0700
Subject: [PATCH 3/3] doc: update list of year2038 platforms

* doc/year2038.texi: Update list of platforms
by adding dates and version numbers and fixing some that
appear to have been misfiled.  Also, list working systems
and versions first, as that helps shorten the list of
failing systems by saying "older versions".
---
 doc/year2038.texi | 58 +++++++++++++++++++++++++----------------------
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/doc/year2038.texi b/doc/year2038.texi
index 3d58659a43..626729578f 100644
--- a/doc/year2038.texi
+++ b/doc/year2038.texi
@@ -51,49 +51,53 @@ gotten around to upgrading their Gnulib module list to include
 @samp{year2038} or @samp{year2038-required}.
 @xref{Large File Support}.
 
-With the @samp{year2038-required} module, @command{configure} fails
-on the following 32-bit platforms (or ABIs in bi-arch systems):
+With the @samp{year2038-required} module, @command{configure} by
+default should work on the following 32-bit platforms (or 32-bit ABIs
+in bi-arch systems):
+
 @itemize
 @item
-Linux with glibc < 2.34 on
+Linux kernel 5.1 (2019) and later with glibc 2.34 (2021) and later on
 x86, arm, mips (32-bit or n32 ABI), powerpc, sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
 @item
-Linux with musl libc on x86,
-@item
-Linux/riscv32,
-@item
-Mac OS X on x86 and powerpc,
-@item
-GNU/Hurd/x86,
-@item
-GNU/kFreeBSD/x86,
-@item
-FreeBSD/x86,
+Linux kernel 5.1 (2019) and later with musl libc 1.2 (2020) and later on x86,
 @item
-MidnightBSD/x86,
+Linux on arc, loong32, riscv32 and x86_64-x32,
 @item
-AIX/powerpc,
+NetBSD 6.0 (2012) and later on x86 and sparc,
 @item
-Solaris 10 and 11 on x86 and sparc,
+OpenBSD 5.5 (2014) and later on x86,
 @item
-Cygwin/x86,
+FreeBSD/arm,
 @item
-Haiku/x86.
+Minix 3.3.
 @end itemize
 
-Whereas no failure will occur on the following 32-bit platforms or ABIs:
+@noindent
+Whereas @command{configure} with @samp{year2038-required} will fail on
+earlier versions of the abovementioned platforms if a version is listed,
+and it will also fail on all versions of the following older 32-bit
+platforms or ABIs:
+
 @itemize
 @item
-Linux/x86 with glibc >= 2.34 on
-x86, arm, mips (32-bit or n32 ABI), powerpc, sparc, s390, hppa, m68k, sh, csky, microblaze, nios2,
+Mac OS X 10.6 (2009) and earlier on x86 and powerpc,
 @item
-Linux/x86_64-x32,
+GNU/Hurd/x86,
 @item
-NetBSD on x86 and sparc,
+GNU/kFreeBSD/x86,
 @item
-OpenBSD/x86,
+FreeBSD/x86 (this port demoted to Tier 2 in FreeBSD 13 [2021]
+and planned to never have 64-bit @code{time_t}),
 @item
-FreeBSD/arm,
+MidnightBSD/x86,
 @item
-Minix 3.3.
+AIX/powerpc (to fix, configure with @samp{CC='gcc -maix64' AR='ar -X64'}),
+@item
+Solaris 11.4 (2018) and earlier on x86 and sparc
+(to fix, configure with @samp{CC='gcc -m64'}),
+@item
+Cygwin 3.3.6 (2022) and earlier on x86,
+@item
+Haiku/x86.
 @end itemize
-- 
2.37.2


  reply	other threads:[~2023-04-10 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10 13:40 recommending AC_SYS_YEAR2038_REQUIRED ? Bruno Haible
2023-04-10 14:12 ` Pádraig Brady
2023-04-10 19:09   ` Zack Weinberg
2023-04-10 19:45     ` Bruno Haible
2023-04-10 19:52     ` Paul Eggert
2023-04-10 21:08       ` Bruno Haible
2023-04-10 22:01         ` Paul Eggert
2023-04-10 21:42       ` Bruno Haible
2023-04-10 22:00         ` Paul Eggert
2023-04-10 22:36           ` Bruno Haible
2023-04-10 23:00             ` Paul Eggert [this message]
2023-04-12  0:10               ` Zack Weinberg
2023-04-19 21:23                 ` Paul Eggert
2023-04-19 22:53                   ` Zack Weinberg
2023-04-12  4:49             ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7fb8ec1e-0db9-dd86-d718-214133f88b53@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=P@draigbrady.com \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=distributions@lists.linux.dev \
    --cc=sam@gentoo.org \
    --cc=zack@owlfolio.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).