[sr #111394] AC_SYS_YEAR2038_RECOMMENDED can't be pacified via environment variable

--8323329-1714636915-1773793612=:3644934
Content-Type: TEXT/plain; CHARSET=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: inline

URL:=0A  <https://savannah.gnu.org/support/?111394>=0A=0A                 S=
ummary: AC_SYS_YEAR2038_RECOMMENDED can't be pacified via=0Aenvironment var=
iable=0A                   Group: Autoconf=0A               Submitter: thes=
amesam=0A               Submitted: Wed 18 Mar 2026 12:26:47 AM UTC=0A      =
          Priority: 5 - Unprioritized=0A                Severity: 3 - Norma=
l=0A                  Status: None=0A                 Privacy: Public=0A   =
          Assigned to: None=0A        Originator Email:=0A             Open=
/Closed: Open=0A         Discussion Lock: Unlocked=0A        Operating Syst=
em: None=0A=0A=0A    ______________________________________________________=
_=0A=0AFollow-up Comments:=0A=0A=0A----------------------------------------=
---------------=0ADate: Wed 18 Mar 2026 12:26:47 AM UTC By: Sam James <thes=
amesam>=0AHi!=0A=0AAC_SYS_YEAR2038_RECOMMENDED has semantics that we (after=
 a lot of work)=0Amanaged to get consensus for, by allowing packages to dem=
and y2038 support and=0Arequiring explicit opt-out (via --disable-year2038)=
 if not available (to=0Aaccept the build will be subpar).=0A=0AThis doesn't=
 seem to accept `export enable_year2038=3Dno` as an explicit=0Aopt-out, and=
 requires `--disable-year2038` on the command line instead, which=0Amakes i=
t hard to opt-out system-wide when we know something is a problem but=0Acan=
't yet fix it.=0A=0AThis happens with i686-gnu (GNU Hurd) where glibc doesn=
't (yet?) support=0Aopting-in to 64-bit time_t:=0A=0A$ ./configure --host=
=3Di686-gnu=0Achecking for  option for large files... -D_FILE_OFFSET_BITS=
=3D64=0Achecking for  option for timestamps after 2038... support not detec=
ted=0Aconfigure: error: in '/tmp/foo':=0Aconfigure: error: could not enable=
 timestamps after mid-January 2038.=0AThis package recommends support for t=
hese later=0Atimestamps. However, to proceed with signed 32-bit=0Atime_t ev=
en though it will fail then, configure with=0A'--disable-year2038'.=0ASee '=
config.log' for more details=0A+verbatim+=0A=0Aconfigure.ac:=0A+verbatim+=
=0AAC_INIT([timetest], [0.1], [], [], [])=0AAC_SYS_YEAR2038_RECOMMENDED=0AA=
C_OUTPUT=0A+verbatim+=0A=0AIt looks like `enable_year2038=3Dyes` is emitted=
 unconditionally in `configure:=0A+verbatim+=0A# Identity of this package.=
=0APACKAGE_NAME=3D'timetest'=0APACKAGE_TARNAME=3D'timetest'=0APACKAGE_VERSI=
ON=3D'0.1'=0APACKAGE_STRING=3D'timetest 0.1'=0APACKAGE_BUGREPORT=3D''=0APAC=
KAGE_URL=3D''=0A=0Aenable_year2038=3Dyes=0Aac_subst_vars=3D'LTLIBOBJS=0ALIB=
OBJS=0A...=0A+verbatim+=0A=0AThe comment above `_AC_SYS_YEAR2038_ENABLE` me=
ntions this:=0A+verbatim+=0A# Depending on which of the YEAR2038 macros was=
 used, add either an=0A# --enable-year2038 or a --disable-year2038 to=0A# t=
he configure script.  This is expanded very late and=0A# therefore there ca=
nnot be any code in the AC_ARG_ENABLE.  The=0A# default value for 'enable_y=
ear2038' is emitted unconditionally=0A# because the generated code always l=
ooks at this variable.=0A+verbatim+=0A=0ATL;DR: Is `enable_year2038=3Dno` a=
s an environment variable supposed to work to=0Asuppress the error?=0A=0A=
=0A=0A=0A=0A=0A=0A    _____________________________________________________=
__=0A=0AReply to this item at:=0A=0A  <https://savannah.gnu.org/support/?11=
1394>=0A=0A_______________________________________________=0AMessage sent v=
ia Savannah=0Ahttps://savannah.gnu.org/=0A
--8323329-1714636915-1773793612=:3644934
Content-Type: APPLICATION/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCabnxTAAKCRCqLAuaBUf3
ToiUAP41J3ZUt/V6Zb+UAUuvVcQm7+CtQ2menRRD/A2VqCd+FwEAuTdMh4QcDJpd
fMY95lx+8S9BSrsnKf6miewEAX9HlgU=
=XJqD
-----END PGP SIGNATURE-----

--8323329-1714636915-1773793612=:3644934--