On Sun, 25 Dec 2022 14:19:11 -0500, Paul Eggert wrote:
> I reviewed your patch and had the following thoughts.
>
> * Gnulib doesn't need AC_SYS_LARGEFILE_REQUIRED or
> AC_SYS_YEAR2038_REQUIRED and they're easy for users to do on their own
> with a simple AS_IF, so let's omit these variants for now, to keep
> things simpler.
I disagree with this. I think it’s important for Autoconf to provide
a built-in, declarative, clearly documented and officially supported
mechanism for packages to declare that they *need* 64-bit off_t and/or
64-bit time_t, rather than just *supporting* them. This is because,
from the earlier discussion, the surviving Linux–based distributions
for ILP32 ABIs might choose *not* to migrate to building everything
with _TIME_BITS=64 or even with _FILE_OFFSET_BITS=64, believing it
more important to preserve binary backward compatibility with
libraries whose ABI changes as a result of either of those macros.
They’re going to try to build stuff with --disable-year2038 and maybe
even with --disable-largefile, and when that bombs out I want it to be
crystal clear from the text of configure.ac that it bombed out because
package X considers 64-bit time_t and/or off_t a requirement.
Please revert that part of your follow-up patch.
> * The documentation incorrectly implies that AC_SYS_LARGEFILE and
> AC_SYS_YEAR2038 are orthogonal, i.e., that one can request large-file
> support and year-2038 support independently. But AC_SYS_YEAR2038
> AC_REQUIREs AC_SYS_LARGEFILE, and one cannot configure with
> --disable-largefile --enable-year2038 and expect things to work. This
> is inherent to the underlying _TIME_BITS mechanism; it's not something
> Autoconf can fix with glibc
I *intended* to make it clear that they are not orthogonal in
practice, but it is not logically necessary for them to be coupled,
and it is, I think, easier to understand what
AC_SYS_{LARGEFILE,YEAR2038} do if we document them as abstractly
orthogonal but then explain that on all the systems where
--enable-year2038 currently does something, it implies
--enable-largefile.
Your changes to the manual are hard for me to read. Is there any
chance you could send a wdiff to the list, after restoring the text
you took out because you took out the _REQUIRED variants?
In the new year, I can look into the possibility of decoupling the
macros’ implementations.
> +*** AC_SYS_LARGEFILE now optionally arranges to widen time_t.
> + It now causes 'configure' to gain an --enable-year2038 option which
> + widens time_t if possible on systems where time_t by default cannot
> + represent file timestamps and other timestamps after January 2038.
> + As with off_t, ino_t, etc., if library ABIs depend on time_t width,
> + applications should be configured consistently with libraries.
> +
> +*** New macro AC_SYS_YEAR2038.
> + This acts like AC_SYS_LARGEFILE, except that it causes 'configure'
> + to default to --enable-year2038. In a future Autoconf version,
> + AC_SYS_LARGEFILE is planned to do this too, so the two macros will
> + become equivalent.
I think you’re still writing documentation with application-colored
glasses on, making it sound like --enable-year2038 has no negative
implications whatsoever. Moreover, I do not believe we have consensus
for AC_SYS_LARGEFILE to become a synonym for AC_SYS_YEAR2038, not even
“in a future Autoconf version.”
Please revert NEWS to my text as well, except for this paragraph
> - AC_SYS_YEAR2038 will also error out if the host system shows signs of
> - supporting dates after Jan 2038 (e.g. in file timestamps) but it can’t
> - figure out how to get a wider time_t; this failure can be overridden
> - with the --disable-year2038 option.
which, on reflection, doesn’t need to be in NEWS, and add this
Enlarging time_t to 64 bits is likely to have the side effect of
enlarging off_t and related types to 64 bits as well, as if you
had used AC_SYS_LARGEFILE. See the manual for details.
to the section on AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
zw
