URL:
  <https://savannah.gnu.org/support/?111394>

                 Summary: AC_SYS_YEAR2038_RECOMMENDED can't be pacified via
environment variable
                   Group: Autoconf
               Submitter: thesamesam
               Submitted: Wed 18 Mar 2026 12:26:47 AM UTC
                Priority: 5 - Unprioritized
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Unlocked
        Operating System: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Wed 18 Mar 2026 12:26:47 AM UTC By: Sam James <thesamesam>
Hi!

AC_SYS_YEAR2038_RECOMMENDED has semantics that we (after a lot of work)
managed to get consensus for, by allowing packages to demand y2038 support and
requiring explicit opt-out (via --disable-year2038) if not available (to
accept the build will be subpar).

This doesn't seem to accept `export enable_year2038=no` as an explicit
opt-out, and requires `--disable-year2038` on the command line instead, which
makes it hard to opt-out system-wide when we know something is a problem but
can't yet fix it.

This happens with i686-gnu (GNU Hurd) where glibc doesn't (yet?) support
opting-in to 64-bit time_t:

$ ./configure --host=i686-gnu
checking for  option for large files... -D_FILE_OFFSET_BITS=64
checking for  option for timestamps after 2038... support not detected
configure: error: in '/tmp/foo':
configure: error: could not enable timestamps after mid-January 2038.
This package recommends support for these later
timestamps. However, to proceed with signed 32-bit
time_t even though it will fail then, configure with
'--disable-year2038'.
See 'config.log' for more details
+verbatim+

configure.ac:
+verbatim+
AC_INIT([timetest], [0.1], [], [], [])
AC_SYS_YEAR2038_RECOMMENDED
AC_OUTPUT
+verbatim+

It looks like `enable_year2038=yes` is emitted unconditionally in `configure:
+verbatim+
# Identity of this package.
PACKAGE_NAME='timetest'
PACKAGE_TARNAME='timetest'
PACKAGE_VERSION='0.1'
PACKAGE_STRING='timetest 0.1'
PACKAGE_BUGREPORT=''
PACKAGE_URL=''

enable_year2038=yes
ac_subst_vars='LTLIBOBJS
LIBOBJS
...
+verbatim+

The comment above `_AC_SYS_YEAR2038_ENABLE` mentions this:
+verbatim+
# Depending on which of the YEAR2038 macros was used, add either an
# --enable-year2038 or a --disable-year2038 to
# the configure script.  This is expanded very late and
# therefore there cannot be any code in the AC_ARG_ENABLE.  The
# default value for 'enable_year2038' is emitted unconditionally
# because the generated code always looks at this variable.
+verbatim+

TL;DR: Is `enable_year2038=no` as an environment variable supposed to work to
suppress the error?







    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/support/?111394>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to