c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* On time64 and Large File Support
@ 2022-11-11  8:38 Sam James
  2022-11-11  9:16 ` Paul Eggert
                   ` (3 more replies)
  0 siblings, 4 replies; 75+ messages in thread
From: Sam James @ 2022-11-11  8:38 UTC (permalink / raw)
  To: Carlos O'Donell via Libc-alpha, autoconf
  Cc: c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert

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

Hi all,

In Gentoo, we've been planning out what we should do for time64 on glibc [0]
and concluded that we need some support in glibc for a newer option. I'll outline
why below.

Proposal: glibc gains two new build-time configure options:
* --enable-hard-time64
* --enable-hard-lfs

These would hard-enable the relevant #defines within glibc's headers and ensure that any
binaries built with such a glibc have both Large File Support (LFS) and time64 support.

I've come to the conclusion it's infeasible to try handle the migration piecemeal. Various
mismatches can and will occur (and while it's more likely with time64, it's possible with LFS
too) [1].

We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
of note [2][3]
1. addition of a new AC_SYS_YEAR2038 macro;
2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.

Indeed, the gnulib version of change #2 is exactly how we ended up with
wget/gnutls breaking [1]. I feel this shows that the only approach
"supported" by glibc right now is untenable.

On reflection and after extensive discussion within Gentoo (although
I don't seek to speak for everybody there) - with special thanks to
David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
we don't think it's feasible to handle this in a piecemeal fashion -
at the very least not without spending a significant & for some,
undesirable amount of time on supporting "obsolete" 32-bit platforms.

Right now, we're forcing the year2038 autoconf cache variable off
to avoid more gnutls/wget instances and plan to do a hard-rebuild (new
set of "profiles" in Gentoo parlance) for 32-bit systems that
enable this. This will be difficult to do properly without having
significant stragglers without some support in glibc as proposed.

All that to say, I don't propose making these options unconditional,
because I think the boat has sailed as of glibc-2.34 [4], and I think
it's fair that autoconf keep the behaviour as described in git master
right now given the situation with glibc, but I don't think it's
a wise path for most distributions to follow.

See also a previous discussion on libc-alpha [5].

What do you think?

[0] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
[1] https://bugs.gentoo.org/828001
[2] https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
[3] https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bc66c26f488975ea9ad22033b9fa28809f4bf65e
[4] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
[5] https://sourceware.org/pipermail/libc-alpha/2022-January/134985.html

best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  8:38 On time64 and Large File Support Sam James
@ 2022-11-11  9:16 ` Paul Eggert
  2022-11-11  9:19   ` Sam James
  2022-11-11 23:48   ` Joseph Myers
  2022-11-11  9:19 ` Florian Weimer
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 75+ messages in thread
From: Paul Eggert @ 2022-11-11  9:16 UTC (permalink / raw)
  To: Sam James, Carlos O'Donell via Libc-alpha, autoconf
  Cc: c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović

On 2022-11-11 00:38, Sam James wrote:
> All that to say, I don't propose making these options unconditional,
> because I think the boat has sailed as of glibc-2.34 [4], and I think
> it's fair that autoconf keep the behaviour as described in git master
> right now given the situation with glibc, but I don't think it's
> a wise path for most distributions to follow.
As a practical matter, I expect that each distro will have to do a 
big-bang move, assuming the distro want to support traditional 32-bit 
platforms at all. It makes little sense to try to have some programs and 
libraries with 32-bit time_t, while others have 64-bit time_t. Just 
switch to 64-bit time_t everywhere.

This is not something distros can put off for long. We're only 15 years 
from when 32-bit time_t stops working. If distros plan to to support 
traditional 32-bit platforms, they really need to do the big-bang move 
soon. They can do it by predefining _TIME_BITS=64 and 
_FILE_OFFSET_BITS=64, or by using the new Autoconf macros, or whatever.

One possible way forward would be for glibc to change its defaults for 
_FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. 
This would make it easier to do a big-bang switch, which is what people 
need to do anyway. The backward-compatibility argument for defaulting 
these to 32 is making less and less sense as time goes on.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:16 ` Paul Eggert
@ 2022-11-11  9:19   ` Sam James
  2022-11-11 23:48   ` Joseph Myers
  1 sibling, 0 replies; 75+ messages in thread
From: Sam James @ 2022-11-11  9:19 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović

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



> On 11 Nov 2022, at 09:16, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 2022-11-11 00:38, Sam James wrote:
>> All that to say, I don't propose making these options unconditional,
>> because I think the boat has sailed as of glibc-2.34 [4], and I think
>> it's fair that autoconf keep the behaviour as described in git master
>> right now given the situation with glibc, but I don't think it's
>> a wise path for most distributions to follow.
> As a practical matter, I expect that each distro will have to do a big-bang move, assuming the distro want to support traditional 32-bit platforms at all. It makes little sense to try to have some programs and libraries with 32-bit time_t, while others have 64-bit time_t. Just switch to 64-bit time_t everywhere.
> 
> This is not something distros can put off for long. We're only 15 years from when 32-bit time_t stops working. If distros plan to to support traditional 32-bit platforms, they really need to do the big-bang move soon. They can do it by predefining _TIME_BITS=64 and _FILE_OFFSET_BITS=64, or by using the new Autoconf macros, or whatever.
> 
> One possible way forward would be for glibc to change its defaults for _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This would make it easier to do a big-bang switch, which is what people need to do anyway. The backward-compatibility argument for defaulting these to 32 is making less and less sense as time goes on.

+1.

I completely agree and I've reached the same conclusion. My suggestion for configure args
was to be a bit more gentle and avoid controversy, but really, your suggestion would work and would
force distros to handle it at the same time, which is best for users.

(And I really did try to make piecemeal work, but I've decided it can't.)

I think we're at risk of distros either putting this off or equivocating which
just harms our users. I should've spoken up at the time of 2.34.

FWIW, musl did this and it really was for the best: https://musl.libc.org/time64.html.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  8:38 On time64 and Large File Support Sam James
  2022-11-11  9:16 ` Paul Eggert
@ 2022-11-11  9:19 ` Florian Weimer
  2022-11-11  9:27   ` Sam James
                     ` (4 more replies)
  2022-11-11 10:25 ` Richard Purdie
  2023-03-01 22:38 ` Eric Blake
  3 siblings, 5 replies; 75+ messages in thread
From: Florian Weimer @ 2022-11-11  9:19 UTC (permalink / raw)
  To: Sam James
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, Frederic Berat

* Sam James:

> In Gentoo, we've been planning out what we should do for time64 on
> glibc [0] and concluded that we need some support in glibc for a newer
> option. I'll outline why below.
>
> Proposal: glibc gains two new build-time configure options:
> * --enable-hard-time64
> * --enable-hard-lfs

We should define new target triplets for this if it's really required.

We need to support legacy binaries on i386.  Few libraries are
explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
to LFS or time64 needs to be evaluated on a per-library basis.  For most
distributions, no one is going to do that work, and we have to stick to
whathever we are building today.

> These would hard-enable the relevant #defines within glibc's headers
> and ensure that any binaries built with such a glibc have both Large
> File Support (LFS) and time64 support.
>
> I've come to the conclusion it's infeasible to try handle the
> migration piecemeal. Various mismatches can and will occur (and while
> it's more likely with time64, it's possible with LFS too) [1].
>
> We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
> of note [2][3]
> 1. addition of a new AC_SYS_YEAR2038 macro;
> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>
> Indeed, the gnulib version of change #2 is exactly how we ended up with
> wget/gnutls breaking [1]. I feel this shows that the only approach
> "supported" by glibc right now is untenable.

AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
for Fedora unfortunately.

I thought the gnulib change has been reverted?

I really wish the rest of GNU would talk to glibc maintainers before
overriding glibc maintainer decisions.  If we cannot revert this in
autoconf (and gnulib), this will very much endanger the Fedora i386
port.  Debian will probably be impacted in the same way.

> On reflection and after extensive discussion within Gentoo (although
> I don't seek to speak for everybody there) - with special thanks to
> David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
> we don't think it's feasible to handle this in a piecemeal fashion -
> at the very least not without spending a significant & for some,
> undesirable amount of time on supporting "obsolete" 32-bit platforms.
>
> Right now, we're forcing the year2038 autoconf cache variable off
> to avoid more gnutls/wget instances and plan to do a hard-rebuild (new
> set of "profiles" in Gentoo parlance) for 32-bit systems that
> enable this. This will be difficult to do properly without having
> significant stragglers without some support in glibc as proposed.

Fedora will have to implement some sort of override as well.  We can't
do a hard rebuild because of compatibility requirements.  There are old
binaries people still use, and contemporary binaries built on relatively
current distributions (distributions that will never switch i386 ABI).

> All that to say, I don't propose making these options unconditional,
> because I think the boat has sailed as of glibc-2.34 [4], and I think
> it's fair that autoconf keep the behaviour as described in git master
> right now given the situation with glibc, but I don't think it's
> a wise path for most distributions to follow.

Hopefully the autoconf change can still be reverted.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:19 ` Florian Weimer
@ 2022-11-11  9:27   ` Sam James
  2022-11-11 11:38     ` Florian Weimer
  2022-11-12  2:20     ` Zack Weinberg
  2022-11-11  9:40   ` Andreas K. Huettel
                     ` (3 subsequent siblings)
  4 siblings, 2 replies; 75+ messages in thread
From: Sam James @ 2022-11-11  9:27 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, Frederic Berat, bug-gnulib

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



> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * Sam James:
> 
>> In Gentoo, we've been planning out what we should do for time64 on
>> glibc [0] and concluded that we need some support in glibc for a newer
>> option. I'll outline why below.
>> 
>> Proposal: glibc gains two new build-time configure options:
>> * --enable-hard-time64
>> * --enable-hard-lfs
> 
> We should define new target triplets for this if it's really required.

I hadn't considered that option. I'll reflect on it. Please let me know
if you have further thoughts on this.

But that said, these binaries are broken anyway in 2038?

> We need to support legacy binaries on i386.  Few libraries are
> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
> to LFS or time64 needs to be evaluated on a per-library basis.  For most
> distributions, no one is going to do that work, and we have to stick to
> whathever we are building today.

While I agree, I don't think it's as well-known that it should be that
these are ABI breaking and require inspection. It's being done ad-hoc
or in many cases, not at all.

Part of the use of this thread is, if nothing else, we can show upstreams
and other distros It if they're confused.

It's very easy to miss that a package has started enabling LFS
and then your opportunity to catch the ABI breakage is gone.

It doesn't help that I (and I suspect most distribution maintainers)
do all development on x86_64 and hence even ABI diffing isn't
going to notice. You have to specifically diff the build system, which I
do, but it's not easy if it's buried deep within gnulib or something.

> 
>> These would hard-enable the relevant #defines within glibc's headers
>> and ensure that any binaries built with such a glibc have both Large
>> File Support (LFS) and time64 support.
>> 
>> I've come to the conclusion it's infeasible to try handle the
>> migration piecemeal. Various mismatches can and will occur (and while
>> it's more likely with time64, it's possible with LFS too) [1].
>> 
>> We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
>> of note [2][3]
>> 1. addition of a new AC_SYS_YEAR2038 macro;
>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>> 
>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>> wget/gnutls breaking [1]. I feel this shows that the only approach
>> "supported" by glibc right now is untenable.
> 
> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
> 
> I thought the gnulib change has been reverted?
> 
> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions.  If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port.  Debian will probably be impacted in the same way.
> 

Right, we need to be unified on this, because it's confusing enough
without unilateralism.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:19 ` Florian Weimer
  2022-11-11  9:27   ` Sam James
@ 2022-11-11  9:40   ` Andreas K. Huettel
  2022-11-11 11:30     ` Florian Weimer
  2022-11-11  9:46   ` Paul Eggert
                     ` (2 subsequent siblings)
  4 siblings, 1 reply; 75+ messages in thread
From: Andreas K. Huettel @ 2022-11-11  9:40 UTC (permalink / raw)
  To: Sam James, libc-alpha
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, Frederic Berat, Florian Weimer

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

> >
> > Proposal: glibc gains two new build-time configure options:
> > * --enable-hard-time64
> > * --enable-hard-lfs
> 
> We should define new target triplets for this if it's really required.
> 

That doesn't really help anyone *but* Debian ...

> We need to support legacy binaries on i386.  Few libraries are
> explicitly dual-ABI.  Whether it's safe to switch libraries above
> glibc to LFS or time64 needs to be evaluated on a per-library
> basis.  For most distributions, no one is going to do that work,
> and we have to stick to whathever we are building today.

... since for Debian the libraries with different ABI end up in different
multiarch paths then.

Anyone with a more, ahem, standard filesystem arrangement has to find
a different solution for the problem of legacy binaries.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:19 ` Florian Weimer
  2022-11-11  9:27   ` Sam James
  2022-11-11  9:40   ` Andreas K. Huettel
@ 2022-11-11  9:46   ` Paul Eggert
  2022-11-11 11:22     ` Florian Weimer
  2022-11-12  4:20   ` Wookey
  2022-11-14  8:39   ` Adam Sampson
  4 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2022-11-11  9:46 UTC (permalink / raw)
  To: Florian Weimer, Sam James
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Frederic Berat

On 2022-11-11 01:19, Florian Weimer wrote:

> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
> 
> I thought the gnulib change has been reverted?

I'm not sure where you got that impression. Bleeding-edge (unreleased) 
Autoconf AC_SYS_LARGEFILE, along with Gnulib AS_SYS_LARGEFILE as shipped 
in several GNU apps already, default to 64-bit time_t on platforms where 
setting _TIME_BITS=64 changes time_t from 32 to 64 bits.  (This is not 
the same as defaulting to AC_SYS_YEAR2038 which *requires* 
wider-than-32-bit time_t, but I expect the difference doesn't matter here.)


> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions.  If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port.  Debian will probably be impacted in the same way.

I'm not sure what is meant by "overriding", as Autoconf etc. are merely 
using a documented glibc feature. Also, the apps in question can be 
configured to stick with 32-bit time_t by using "./configure 
--disable-year2038" and/or setting the corresponding cache variables, so 
distros continue to have a choice about which time_t flavor they prefer.

What I'm gathering from your email is that 32-bit Fedora x86 needs an 
easy way to say "hold on, I want 32-bit time_t to be the default for all 
'configure' runs". If the --disable-year2038 option of 'configure' isn't 
enough, and/or setting the appropriate cache variables isn't enough, 
what other configuration method would you like?

Also, how does this issue with 64-bit time_t differ from the decades-old 
issue with 64-bit off_t? AC_SYS_LARGEFILE has long defaulted to 64-bit 
off_t, and Autoconf-generated configure scripts have long had 
--disable-largefile options and related cache variables much the same 
way that they're now dealing with 64-bit time_t. Is the difference 
merely that time_t is more widely used than off_t, so the ABI problems 
are more likely now?

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  8:38 On time64 and Large File Support Sam James
  2022-11-11  9:16 ` Paul Eggert
  2022-11-11  9:19 ` Florian Weimer
@ 2022-11-11 10:25 ` Richard Purdie
  2023-03-01 22:38 ` Eric Blake
  3 siblings, 0 replies; 75+ messages in thread
From: Richard Purdie @ 2022-11-11 10:25 UTC (permalink / raw)
  To: Sam James, Carlos O'Donell via Libc-alpha, autoconf
  Cc: c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert

On Fri, 2022-11-11 at 08:38 +0000, Sam James wrote:
> In Gentoo, we've been planning out what we should do for time64 on glibc [0]
> and concluded that we need some support in glibc for a newer option. I'll outline
> why below.
> 
> Proposal: glibc gains two new build-time configure options:
> * --enable-hard-time64
> * --enable-hard-lfs
> 
> These would hard-enable the relevant #defines within glibc's headers and ensure that any
> binaries built with such a glibc have both Large File Support (LFS) and time64 support.
> 
> I've come to the conclusion it's infeasible to try handle the migration piecemeal. Various
> mismatches can and will occur (and while it's more likely with time64, it's possible with LFS
> too) [1].

As a data point, Yocto Project has been debating this a bit. Based upon
what I've seen so far, I reached a similar conclusion, that we probably
needed to "just switch". As a source based system, the situation is
quite different to distros with binary feeds though.

My questions are around how much warning we can give people where code
is doing something it shouldn't and I don't have a good feel for how
much risk we're putting onto users with existing runtimes.

Cheers,

Richard





^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:46   ` Paul Eggert
@ 2022-11-11 11:22     ` Florian Weimer
  2022-11-11 19:56       ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Florian Weimer @ 2022-11-11 11:22 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Frederic Berat

* Paul Eggert:

> On 2022-11-11 01:19, Florian Weimer wrote:
>
>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>> for Fedora unfortunately.
>> I thought the gnulib change has been reverted?
>
> I'm not sure where you got that impression. Bleeding-edge (unreleased)
> Autoconf AC_SYS_LARGEFILE, along with Gnulib AS_SYS_LARGEFILE as
> shipped in several GNU apps already, default to 64-bit time_t on
> platforms where setting _TIME_BITS=64 changes time_t from 32 to 64
> bits.  (This is not the same as defaulting to AC_SYS_YEAR2038 which
> *requires* wider-than-32-bit time_t, but I expect the difference
> doesn't matter here.)

Ugh.

>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions.  If we cannot revert this in
>> autoconf (and gnulib), this will very much endanger the Fedora i386
>> port.  Debian will probably be impacted in the same way.
>
> I'm not sure what is meant by "overriding", as Autoconf etc. are
> merely using a documented glibc feature. Also, the apps in question
> can be configured to stick with 32-bit time_t by using "./configure 
> --disable-year2038" and/or setting the corresponding cache variables,
>   so distros continue to have a choice about which time_t flavor they
>  prefer.

There are many documented toolchain features that change ABI.  It's up
to developers to determine whether it's safe to enable them.  For Y2038
support, that's obviously quite desirable in principle.  But we (glibc
upstream) looked at it and concluded that we just can't introduce it by
default and maintain backwards compatibility with existing binaries,
which is of paramount importance for i386.

I never expected GNU to switch i386 to time64 by default.  Attempting
this switch is a huge distraction and prevents many of us from working
on more important matters that benefit GNU in much more direct ways.

> What I'm gathering from your email is that 32-bit Fedora x86 needs an
> easy way to say "hold on, I want 32-bit time_t to be the default for
> all 'configure' runs". If the --disable-year2038 option of 'configure'
> isn't enough, and/or setting the appropriate cache variables isn't
> enough, what other configuration method would you like?

I don't know yet.  Fortunately, any issues should be quite visibile in
the distribution DWARF data.  If we put the time32 switch in place, we
should be able to tell whether it's effective enough in practice.

> Also, how does this issue with 64-bit time_t differ from the
> decades-old issue with 64-bit off_t? AC_SYS_LARGEFILE has long
> defaulted to 64-bit off_t, and Autoconf-generated configure scripts
> have long had --disable-largefile options and related cache variables
> much the same way that they're now dealing with 64-bit time_t. Is the
> difference merely that time_t is more widely used than off_t, so the
> ABI problems are more likely now?

LFS issues have been with us for a long time, and packages and
distributions have workarounds for it (e.g., using off64_t or long long
in public headers).  What we have today mostly works.  But it's unknown
whether existing AC_SYS_LARGEFILE users require any additional work for
time64 changes.  It's also not clear how to approach this from an
individual upstream perspective if different distributions have
different requirements.  I just don't see many libraries adopting a
dual-ABI approach like glibc did, or spending much work on this.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:40   ` Andreas K. Huettel
@ 2022-11-11 11:30     ` Florian Weimer
  2022-11-11 19:01       ` Andreas K. Huettel
  0 siblings, 1 reply; 75+ messages in thread
From: Florian Weimer @ 2022-11-11 11:30 UTC (permalink / raw)
  To: Andreas K. Huettel
  Cc: Sam James, libc-alpha, autoconf, c-std-porting, Zack Weinberg,
	David Seifert, Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, Frederic Berat

* Andreas K. Huettel:

>> >
>> > Proposal: glibc gains two new build-time configure options:
>> > * --enable-hard-time64
>> > * --enable-hard-lfs
>> 
>> We should define new target triplets for this if it's really required.
>> 
>
> That doesn't really help anyone *but* Debian ...
>
>> We need to support legacy binaries on i386.  Few libraries are
>> explicitly dual-ABI.  Whether it's safe to switch libraries above
>> glibc to LFS or time64 needs to be evaluated on a per-library
>> basis.  For most distributions, no one is going to do that work,
>> and we have to stick to whathever we are building today.
>
> ... since for Debian the libraries with different ABI end up in different
> multiarch paths then.

I didn't expect co-installability as a requirement.  But yes, if that's
the goal, we need non-overlapping paths.

> Anyone with a more, ahem, standard filesystem arrangement has to find
> a different solution for the problem of legacy binaries.

We can have lib, lib64, libx32, and lib32t quite easily, that's not the
problem.  What's missing is ldconfig support.  The previous three x86
architectures have ELF-level selectors; we might need something special
there as well.

Debian does not have a multi-arch ldconfig, either.  Their path layout
isn't really ideal for that because it lacks a marker directory like
glibc-hwcaps that would allow ldconfig to build the cache from file
system content without knowledge of the exact architecture list.

Maybe I can get justification for upstreaming some form of multi-arch
support in the toolchain.  But I find it difficult to make this a top
priority.  (We currently use the upstream path layout in our
distributions.)

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:27   ` Sam James
@ 2022-11-11 11:38     ` Florian Weimer
  2022-11-11 20:12       ` Paul Eggert
  2022-11-12  2:20     ` Zack Weinberg
  1 sibling, 1 reply; 75+ messages in thread
From: Florian Weimer @ 2022-11-11 11:38 UTC (permalink / raw)
  To: Sam James
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, Frederic Berat, bug-gnulib

* Sam James:

>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>> 
>> * Sam James:
>> 
>>> In Gentoo, we've been planning out what we should do for time64 on
>>> glibc [0] and concluded that we need some support in glibc for a newer
>>> option. I'll outline why below.
>>> 
>>> Proposal: glibc gains two new build-time configure options:
>>> * --enable-hard-time64
>>> * --enable-hard-lfs
>> 
>> We should define new target triplets for this if it's really required.
>
> I hadn't considered that option. I'll reflect on it. Please let me know
> if you have further thoughts on this.
>
> But that said, these binaries are broken anyway in 2038?

No, I expect users to run them in time-shifted VMs or containers.
Wrong dates are better than no ability to run anything at all.

And whoever can recompile to switch to time64 can just recompile for a
64-bit target.  There are some embedded users that stick to 32-bit for
cost savings, but I think the cost allocation is quite wrong: They save
a bit on per-unit costs, but they do not really contribute back to GNU
(and most don't even use glibc, although there is some use out there).

>> We need to support legacy binaries on i386.  Few libraries are
>> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
>> to LFS or time64 needs to be evaluated on a per-library basis.  For most
>> distributions, no one is going to do that work, and we have to stick to
>> whathever we are building today.
>
> While I agree, I don't think it's as well-known that it should be that
> these are ABI breaking and require inspection. It's being done ad-hoc
> or in many cases, not at all.
>
> Part of the use of this thread is, if nothing else, we can show upstreams
> and other distros It if they're confused.
>
> It's very easy to miss that a package has started enabling LFS
> and then your opportunity to catch the ABI breakage is gone.
>
> It doesn't help that I (and I suspect most distribution maintainers)
> do all development on x86_64 and hence even ABI diffing isn't
> going to notice. You have to specifically diff the build system, which I
> do, but it's not easy if it's buried deep within gnulib or something.

I really assumed that setting the default in glibc would solve this for
everyone: binary distributions keep using time32, and source-based
embedded distributions can switch to time64 if they want to. *sigh*

I mean, we have things like more compact stack usage through certain
ABI-breaking GCC options.  The kernel can use those safely, but few
people attempt to apply them to userspace.  There, having the right
default in the toolchain is sufficient.  I didn't expect time64 to be
different.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11 11:30     ` Florian Weimer
@ 2022-11-11 19:01       ` Andreas K. Huettel
  2022-11-11 19:28         ` Palmer Dabbelt
  0 siblings, 1 reply; 75+ messages in thread
From: Andreas K. Huettel @ 2022-11-11 19:01 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Sam James, libc-alpha, autoconf, c-std-porting, Zack Weinberg,
	David Seifert, Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, Frederic Berat

> >> We need to support legacy binaries on i386.  Few libraries are
> >> explicitly dual-ABI.  Whether it's safe to switch libraries above
> >> glibc to LFS or time64 needs to be evaluated on a per-library
> >> basis.  For most distributions, no one is going to do that work,
> >> and we have to stick to whathever we are building today.
> >
> > ... since for Debian the libraries with different ABI end up in different
> > multiarch paths then.
> 
> I didn't expect co-installability as a requirement.  But yes, if that's
> the goal, we need non-overlapping paths.

Doesn't that requirement come automatically with "we need to support legacy
binaries"? How else would that work?

> > Anyone with a more, ahem, standard filesystem arrangement has to find
> > a different solution for the problem of legacy binaries.
> 
> We can have lib, lib64, libx32, and lib32t quite easily, that's not the
> problem.  What's missing is ldconfig support.  The previous three x86
> architectures have ELF-level selectors; we might need something special
> there as well.

Yup. I was thinking of lib32n (which won't collide with anything out
there), but the selector problem remains.

[Apart from all further fun problems with library paths unexpected by
unwary upstreams... riscv64 (lib64/lp64d, lib64/lp64, lib32/ilp32d, 
lib32/ilp32) and mips64 (lib, lib32, lib64) send their regards.]


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11 19:01       ` Andreas K. Huettel
@ 2022-11-11 19:28         ` Palmer Dabbelt
  0 siblings, 0 replies; 75+ messages in thread
From: Palmer Dabbelt @ 2022-11-11 19:28 UTC (permalink / raw)
  To: libc-alpha
  Cc: fweimer, sam, libc-alpha, autoconf, c-std-porting, zack, soap,
	toolchain, arsen, eggert, fberat

On Fri, 11 Nov 2022 11:01:50 PST (-0800), libc-alpha@sourceware.org wrote:
>> >> We need to support legacy binaries on i386.  Few libraries are
>> >> explicitly dual-ABI.  Whether it's safe to switch libraries above
>> >> glibc to LFS or time64 needs to be evaluated on a per-library
>> >> basis.  For most distributions, no one is going to do that work,
>> >> and we have to stick to whathever we are building today.
>> >
>> > ... since for Debian the libraries with different ABI end up in different
>> > multiarch paths then.
>> 
>> I didn't expect co-installability as a requirement.  But yes, if that's
>> the goal, we need non-overlapping paths.
>
> Doesn't that requirement come automatically with "we need to support legacy
> binaries"? How else would that work?
>
>> > Anyone with a more, ahem, standard filesystem arrangement has to find
>> > a different solution for the problem of legacy binaries.
>> 
>> We can have lib, lib64, libx32, and lib32t quite easily, that's not the
>> problem.  What's missing is ldconfig support.  The previous three x86
>> architectures have ELF-level selectors; we might need something special
>> there as well.
>
> Yup. I was thinking of lib32n (which won't collide with anything out
> there), but the selector problem remains.
>
> [Apart from all further fun problems with library paths unexpected by
> unwary upstreams... riscv64 (lib64/lp64d, lib64/lp64, lib32/ilp32d, 
> lib32/ilp32) and mips64 (lib, lib32, lib64) send their regards.]

I don't want to derail the thread, but sorry again for the RISC-V bits 
there.  IMO we can fix it without an ABI break via adding some new 
paths, I just don't know what they should be.  Happy to hear if anyone 
has suggestions...

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11 11:22     ` Florian Weimer
@ 2022-11-11 19:56       ` Paul Eggert
  0 siblings, 0 replies; 75+ messages in thread
From: Paul Eggert @ 2022-11-11 19:56 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Frederic Berat

On 2022-11-11 03:22, Florian Weimer wrote:

> Fortunately, any issues should be quite visibile in
> the distribution DWARF data.  If we put the time32 switch in place, we
> should be able to tell whether it's effective enough in practice.

OK, thanks; if problems turn up in that area please let the 
Autoconf/Gnulib people know what we can do to help address them.


> LFS issues have been with us for a long time, and packages and
> distributions have workarounds for it (e.g., using off64_t or long long
> in public headers).  What we have today mostly works.  But it's unknown
> whether existing AC_SYS_LARGEFILE users require any additional work for
> time64 changes.

If what we have today mostly works, then it works for blkcnt_t, dev_t, 
ino_t, off_t and rlim_t, all of whose widths differ on 32-bit x86 glibc 
depending on whether one compiles with -D_FILE_OFFSET_BITS=64. So 
there's some precedent for hoping that what we have today will mostly 
work for time_t and -D_TIME_BITS=64 as well.

In hindsight, perhaps it would have been better to have 
_FILE_OFFSET_BITS=64 also control time_t width, since that would have 
made for one less configure-time option to worry about. (After all 
rlim_t can hold 64-bit counts of seconds, so why not time_t?) I suppose 
it's too late for that now, though.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11 11:38     ` Florian Weimer
@ 2022-11-11 20:12       ` Paul Eggert
  0 siblings, 0 replies; 75+ messages in thread
From: Paul Eggert @ 2022-11-11 20:12 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Frederic Berat, bug-gnulib, Sam James

On 2022-11-11 03:38, Florian Weimer wrote:
>> But that said, these binaries are broken anyway in 2038?
> No, I expect users to run them in time-shifted VMs or containers.

That's reasonable for systems where accurate timestamps are not 
important and where time_t width mismatches would just get in the way.

However, if this is the expected approach, I suggest having a standard 
and well-documented way to timeshift VMs and containers, and unless you 
want to cede the field entirely to other platforms this documentation 
effort and testing should be done now rather than in the year 2037. 
(Another thing to add to your bulging to-do list....)

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:16 ` Paul Eggert
  2022-11-11  9:19   ` Sam James
@ 2022-11-11 23:48   ` Joseph Myers
  1 sibling, 0 replies; 75+ messages in thread
From: Joseph Myers @ 2022-11-11 23:48 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović

On Fri, 11 Nov 2022, Paul Eggert wrote:

> One possible way forward would be for glibc to change its defaults for
> _FILE_OFFSET_BITS and _TIME_BITS to be 64, in the next major release. This

See my notes at 
<https://sourceware.org/pipermail/libc-alpha/2019-January/100410.html> on 
what would be involved in changing the default *just of _FILE_OFFSET_BITS* 
for user programs, depending on whether the mode used to build glibc tests 
is also changed (but without changing the settings used for building glibc 
itself, which is much more complicated).

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:27   ` Sam James
  2022-11-11 11:38     ` Florian Weimer
@ 2022-11-12  2:20     ` Zack Weinberg
  2022-11-12  3:57       ` Sam James
  2022-11-12 18:19       ` Paul Eggert
  1 sibling, 2 replies; 75+ messages in thread
From: Zack Weinberg @ 2022-11-12  2:20 UTC (permalink / raw)
  To: Sam James
  Cc: Florian Weimer, Paul Eggert, libc-alpha, autoconf, c-std-porting,
	toolchain, bug-gnulib

Sam James <sam@gentoo.org> writes:
>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>> We need to support legacy binaries on i386.  Few libraries are
>> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
>> to LFS or time64 needs to be evaluated on a per-library basis.  For most
>> distributions, no one is going to do that work, and we have to stick to
>> whathever we are building today.
>
> While I agree, I don't think it's as well-known that it should be that
> these are ABI breaking and require inspection. It's being done ad-hoc
> or in many cases, not at all.
>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>> contains two changes of note [2][3]
>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>> 
>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>> "supported" by glibc right now is untenable.
>> 
>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>> for Fedora unfortunately.
>> 
>> I thought the gnulib change has been reverted?
>> 
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions.

There seems to be a disconnect between Paul Eggert’s position on these
changes and everyone else on this thread’s position.

I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
overriding the glibc maintainers. Rather, I think he was only thinking
about applications, not libraries, and only about source distribution.
If an application is being built on the machine where it’ll be used, and
both it and the system support building it with 64-bit time_t and off_t,
*why wouldn’t you*?  It has no impact on anything else to do that, and
it future-proofs your installataion.

But everyone else is worrying about cases where, either, an application
is built with 64-bit time_t and/or off_t and then copied to a different
system where the underlying libraries *don’t* support that, or a *shared
library* is rebuilt with 64-bit time_t and/or off_t and that silently
changes its ABI out from under programs that use it.

(It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
difficult for any shared library other than glibc to offer *both* time_t
and time64_t binary interfaces.)

(It’s also unfortunate that, 20+ years after the invention of ELF symbol
versioning, it’s still ridiculously difficult.  So many macros and
assembly hacks and fighting with libtool.  But I digress.)

I am honestly not sure what to do about this in the long term, but for
the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
added it, and should make it safe for Fedora and Gentoo to drop in 2.72
in order to unblock C23 testing — am I correct?  It doesn’t resolve the
larger issue, but it gives us more time to think about what the
resolution ought to be.

What do you think?
zw

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  2:20     ` Zack Weinberg
@ 2022-11-12  3:57       ` Sam James
  2022-11-12 14:16         ` Zack Weinberg
  2022-11-12 18:19       ` Paul Eggert
  1 sibling, 1 reply; 75+ messages in thread
From: Sam James @ 2022-11-12  3:57 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Florian Weimer, Paul Eggert, Carlos O'Donell via Libc-alpha,
	autoconf, c-std-porting, toolchain, bug-gnulib

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



> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha <libc-alpha@sourceware.org> wrote:
> 
> Sam James <sam@gentoo.org> writes:
>>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>>> We need to support legacy binaries on i386.  Few libraries are
>>> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
>>> to LFS or time64 needs to be evaluated on a per-library basis.  For most
>>> distributions, no one is going to do that work, and we have to stick to
>>> whathever we are building today.
>> 
>> While I agree, I don't think it's as well-known that it should be that
>> these are ABI breaking and require inspection. It's being done ad-hoc
>> or in many cases, not at all.
> …
>>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>>> contains two changes of note [2][3]
>>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>>> 
>>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>>> "supported" by glibc right now is untenable.
>>> 
>>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>>> for Fedora unfortunately.
>>> 
>>> I thought the gnulib change has been reverted?
>>> 
>>> I really wish the rest of GNU would talk to glibc maintainers before
>>> overriding glibc maintainer decisions.
> 
> There seems to be a disconnect between Paul Eggert’s position on these
> changes and everyone else on this thread’s position.
> 
> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.
> If an application is being built on the machine where it’ll be used, and
> both it and the system support building it with 64-bit time_t and off_t,
> *why wouldn’t you*?  It has no impact on anything else to do that, and
> it future-proofs your installataion.
> 
> But everyone else is worrying about cases where, either, an application
> is built with 64-bit time_t and/or off_t and then copied to a different
> system where the underlying libraries *don’t* support that, or a *shared
> library* is rebuilt with 64-bit time_t and/or off_t and that silently
> changes its ABI out from under programs that use it.
> 

Precisely.

> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)
> 
> (It’s also unfortunate that, 20+ years after the invention of ELF symbol
> versioning, it’s still ridiculously difficult.  So many macros and
> assembly hacks and fighting with libtool.  But I digress.)
> 
> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
> in order to unblock C23 testing — am I correct?  It doesn’t resolve the
> larger issue, but it gives us more time to think about what the
> resolution ought to be.
> 
> What do you think?

This is really I think the best option while allowing us time & space
to complete the larger discussion.

We keep AC_SYS_YEAR2038 which lets upstreams opt in,
but it avoids the risk of sudden LFS-into-time64 rollover.

Year 2038 work is really important (which is why I brought
up the topic) but I don't want confusion around it to make
people avoid adopting 2.72 or leave us without a 2.72
at all.

I do sympathise with Paul's position, but I'm not
a believer in piecemeal anyway now and it's fair to say there's no
consensus on this yet.

Paul's point Is fair that distros who wish can set the cache var to
ff, so *if* you and Paul want to keep it in.

I could live with a bigger "please check this!" in NEWS. I don't think it's a
total disaster as long as we brief distros first, as we're already
doing it for gnuilb & upstreams may well end up doing themselves,
so the train is on its way out of the station anyway.

(I think we need to keep the discussion going on that front,
but I think it'd be wrong to let it block this release, as it's
not a simple problem and I'm still unsure how I fully feel
about the issues at its core.)

I don't think it's conservative to make a macro suddenly
do a new thing which might require testing on the part
of projects using autoconf. Even if I get the aim.

And if we want to change it later, we still can. If we all
magically reach consensus in a month, there's nothing
stopping that being pursued.

So let's go for keep AC_SYS_YEAR2038 only?

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:19 ` Florian Weimer
                     ` (2 preceding siblings ...)
  2022-11-11  9:46   ` Paul Eggert
@ 2022-11-12  4:20   ` Wookey
  2022-11-12  4:28     ` Sam James
  2022-11-12 18:33     ` Paul Eggert
  2022-11-14  8:39   ` Adam Sampson
  4 siblings, 2 replies; 75+ messages in thread
From: Wookey @ 2022-11-12  4:20 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne

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

On 2022-11-11 10:19 +0100, Florian Weimer wrote:

Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf
in Debian.  We are currently doing a preliminary bootstrap to see what
breaks. We strongly suspect that only a wholesale rebuild for the new
ABI (i.e a new Debian architecture) is practical, but have not yet
entirely ruled out attempting a migration within the existing armhf
arch.

A test of this in 2020 by Arnd Bergman found that too much stuff was broken.
https://lists.debian.org/debian-arm/2020/02/msg00024.html
Things now look much more mature as some others have already fixed various things.
https://lists.debian.org/debian-arm/2022/09/msg00012.html
https://lists.debian.org/debian-arm/2022/10/msg00020.html

I've not got far with bootstrapping but had got as for as noting that
LFS and 64bit timet are tied together in glibc (setting _TIME_BITS=64
requires setting _FILE_OFFSET_BITS=64). So that's two lots of
interacting ABI changes, which doesn't make things any simpler.

> * Sam James
> 
> > In Gentoo, we've been planning out what we should do for time64 on
> > glibc [0] and concluded that we need some support in glibc for a newer
> > option. I'll outline why below.
> >
> > Proposal: glibc gains two new build-time configure options:
> > * --enable-hard-time64
> > * --enable-hard-lfs

I don't quite follow the logic of this. glibc already has build-time macros to set these two things:
_TIME_BITS=64
_FILE_OFFSET_BITS=64

why do we need configure options too?

> We should define new target triplets for this if it's really required.

We have been coming to the conclusion that this is necessary. If it's
not feasible to migrate with the existing armhf (and maybe i386)
architectures, then we need a new triplet to define this ABI and (in
debian, match the dkpg arch name).

> We need to support legacy binaries on i386.  Few libraries are
> explicitly dual-ABI.  Whether it's safe to switch libraries above glibc
> to LFS or time64 needs to be evaluated on a per-library basis.  For most
> distributions, no one is going to do that work, and we have to stick to
> whathever we are building today.

Well Debian has started this work.

> > These would hard-enable the relevant #defines within glibc's headers
> > and ensure that any binaries built with such a glibc have both Large
> > File Support (LFS) and time64 support.
> >
> > I've come to the conclusion it's infeasible to try handle the
> > migration piecemeal. Various mismatches can and will occur (and while
> > it's more likely with time64, it's possible with LFS too) [1].

Right. This is definitely a problem, as both items will be in structs
that are exposed in ABIs in various places. What I've not yet got a
handle on is just how big a problem. Debian has done large ABI
transitions before within an architecture (glibc5->6), (GCC 4.0 C++
ABI), and (long-double transition (from 64 to 128 bits), on a subset of arches), so it is
possible. (That long-double transition is the most like this
transition, because it involves types that can appear in C and C++
ABI). https://lists.debian.org/debian-devel/2007/05/msg01173.html


> > We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
> > of note [2][3]
> > 1. addition of a new AC_SYS_YEAR2038 macro;
> > 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.

Which is the opposite way round to glibc, where _TIME_BITS=64 requires
_FILE_OFFSET_BITS=64, but not the other way round
(_FILE_OFFSET_BITS=64, can be set on its own). Am I misunderstanding something here?

It doesn't seem right to me that AC_SYS_LARGEFILE should imply
AC_SYS_YEAR2038. What is the reasoning behind that?

> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions.  If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port.  Debian will probably be impacted in the same way.

I need to read around all this as I have only just become aware that
the LFS thing is entangled with the timet_64 thing. Is there a good
place to read _why_ one implies the other? It definitely complicates
matters.

> > On reflection and after extensive discussion within Gentoo (although
> > I don't seek to speak for everybody there) - with special thanks to
> > David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
> > we don't think it's feasible to handle this in a piecemeal fashion -
> > at the very least not without spending a significant & for some,
> > undesirable amount of time on supporting "obsolete" 32-bit platforms.

Distros need to co-ordinate on this. If there are going to be new
triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
them and use them. If distros are happy to migrate to these ABIs
within the existing arm-linux-gnueabihf and i386-linux-gnu (or
i686-linux-gnu) then we should do that.

If half the distros migrate within the existing triplet and the rest use
a new one, that sounds like a recipie for much confusion.

I could write more, but I'll swot up a bit first :-)

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  4:20   ` Wookey
@ 2022-11-12  4:28     ` Sam James
  2022-11-12  4:56       ` Wookey
  2022-11-12 18:33     ` Paul Eggert
  1 sibling, 1 reply; 75+ messages in thread
From: Sam James @ 2022-11-12  4:28 UTC (permalink / raw)
  To: Wookey
  Cc: Florian Weimer, Carlos O'Donell via Libc-alpha,
	Autoconf Development, c-std-porting, Zack Weinberg,
	David Seifert, Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne

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



> On 12 Nov 2022, at 04:20, Wookey <wookey@wookware.org> wrote:
> 
> On 2022-11-11 10:19 +0100, Florian Weimer wrote:
> 
> Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf
> in Debian.  We are currently doing a preliminary bootstrap to see what
> breaks. We strongly suspect that only a wholesale rebuild for the new
> ABI (i.e a new Debian architecture) is practical, but have not yet
> entirely ruled out attempting a migration within the existing armhf
> arch.
> 
> [snip]
> 
>> * Sam James
>> 
>>> In Gentoo, we've been planning out what we should do for time64 on
>>> glibc [0] and concluded that we need some support in glibc for a newer
>>> option. I'll outline why below.
>>> 
>>> Proposal: glibc gains two new build-time configure options:
>>> * --enable-hard-time64
>>> * --enable-hard-lfs
> 
> I don't quite follow the logic of this. glibc already has build-time macros to set these two things:
> _TIME_BITS=64
> _FILE_OFFSET_BITS=64
> 
> why do we need configure options too?

How do you make sure that every program built uses it? Not every
program respects CPPFLAGS and even in CFLAGS, it's a bit
of a nuisance.

If you patch GCC, you don't cover Clang. If you patch system
compilers, that's messy but also doesn't help with custom-built programs.

Of course, we could just patch glibc and cheerily jam it in the headers,
but we run into the kind of problems that Joseph Myers mentions then,
I think (basically I'd want to make sure we do it right.)

> 
>>> We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
>>> of note [2][3]
>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
> 
> Which is the opposite way round to glibc, where _TIME_BITS=64 requires
> _FILE_OFFSET_BITS=64, but not the other way round
> (_FILE_OFFSET_BITS=64, can be set on its own). Am I misunderstanding something here?
> 

I wonder the same. I don't think it's obvious, and it may not be obvious
to people writing software using autoconf either...

> It doesn't seem right to me that AC_SYS_LARGEFILE should imply
> AC_SYS_YEAR2038. What is the reasoning behind that?
> 
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions.  If we cannot revert this in
>> autoconf (and gnulib), this will very much endanger the Fedora i386
>> port.  Debian will probably be impacted in the same way.
> 
> I need to read around all this as I have only just become aware that
> the LFS thing is entangled with the timet_64 thing. Is there a good
> place to read _why_ one implies the other? It definitely complicates
> matters.

time64 has to imply LFS because of some structures like stat including
both off_t (LFS) and st_atim (time64), I think. Some of it is internal too.

Or do you mean LFS => time64? I have no idea for why that's
entangled in autoconf and gnulib.

> 
>>> On reflection and after extensive discussion within Gentoo (although
>>> I don't seek to speak for everybody there) - with special thanks to
>>> David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
>>> we don't think it's feasible to handle this in a piecemeal fashion -
>>> at the very least not without spending a significant & for some,
>>> undesirable amount of time on supporting "obsolete" 32-bit platforms.
> 
> Distros need to co-ordinate on this. If there are going to be new
> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
> them and use them. If distros are happy to migrate to these ABIs
> within the existing arm-linux-gnueabihf and i386-linux-gnu (or
> i686-linux-gnu) then we should do that.
> 
> If half the distros migrate within the existing triplet and the rest use
> a new one, that sounds like a recipie for much confusion.
> 

100%. And also on sharing patches and known problems
and experience with the migration. All of it!

> I could write more, but I'll swot up a bit first :-)

It's not easy to find much about all of this! I almost
felt like I was missing something at first. :)

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  4:28     ` Sam James
@ 2022-11-12  4:56       ` Wookey
  2022-11-12  4:59         ` Sam James
  0 siblings, 1 reply; 75+ messages in thread
From: Wookey @ 2022-11-12  4:56 UTC (permalink / raw)
  To: Sam James
  Cc: Florian Weimer, Carlos O'Donell via Libc-alpha,
	Autoconf Development, c-std-porting, Zack Weinberg,
	David Seifert, Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne

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

On 2022-11-12 04:28 +0000, Sam James wrote:
> 
> 
> > On 12 Nov 2022, at 04:20, Wookey <wookey@wookware.org> wrote:
> > 
> > Distros need to co-ordinate on this. If there are going to be new
> > triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
> > them and use them. If distros are happy to migrate to these ABIs
> > within the existing arm-linux-gnueabihf and i386-linux-gnu (or
> > i686-linux-gnu) then we should do that.
> > 
> > If half the distros migrate within the existing triplet and the rest use
> > a new one, that sounds like a recipie for much confusion.
> > 
> 
> 100%. And also on sharing patches and known problems
> and experience with the migration. All of it!

OK. It seems that the time is right to have this conversation. So we should agree on a place to do it.

We have used the linaro cross-distro list in the past as it is
intended for this sort of cross-cutting discussions. I can't think of
a better place?
https://lists.linaro.org/mailman3/lists/cross-distro.lists.linaro.org/

Some of the right people are probably already there, but we should
encourage others with relevant expertise to join.


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  4:56       ` Wookey
@ 2022-11-12  4:59         ` Sam James
  0 siblings, 0 replies; 75+ messages in thread
From: Sam James @ 2022-11-12  4:59 UTC (permalink / raw)
  To: Wookey
  Cc: Florian Weimer, Carlos O'Donell via Libc-alpha,
	Autoconf Development, c-std-porting, Zack Weinberg,
	David Seifert, Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne

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



> On 12 Nov 2022, at 04:56, Wookey <wookey@wookware.org> wrote:
> 
> On 2022-11-12 04:28 +0000, Sam James wrote:
>> 
>> 
>>> On 12 Nov 2022, at 04:20, Wookey <wookey@wookware.org> wrote:
>>> 
>>> Distros need to co-ordinate on this. If there are going to be new
>>> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
>>> them and use them. If distros are happy to migrate to these ABIs
>>> within the existing arm-linux-gnueabihf and i386-linux-gnu (or
>>> i686-linux-gnu) then we should do that.
>>> 
>>> If half the distros migrate within the existing triplet and the rest use
>>> a new one, that sounds like a recipie for much confusion.
>>> 
>> 
>> 100%. And also on sharing patches and known problems
>> and experience with the migration. All of it!
> 
> OK. It seems that the time is right to have this conversation. So we should agree on a place to do it.
> 
> We have used the linaro cross-distro list in the past as it is
> intended for this sort of cross-cutting discussions. I can't think of
> a better place?
> https://lists.linaro.org/mailman3/lists/cross-distro.lists.linaro.org/
> 
> Some of the right people are probably already there, but we should
> encourage others with relevant expertise to join.
> 

That list is new to me (sub'd now) but I'm fine with using it as long
as linaro are still OK with us using it and them maintaining it.

Thanks for taking the initiative!

If they aren't, we could request a list from lists.linux.dev
(Linux Foundation).

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  3:57       ` Sam James
@ 2022-11-12 14:16         ` Zack Weinberg
  2022-11-12 17:41           ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Zack Weinberg @ 2022-11-12 14:16 UTC (permalink / raw)
  To: Sam James
  Cc: Florian Weimer, Paul Eggert, Carlos O'Donell via Libc-alpha,
	autoconf, c-std-porting, toolchain, bug-gnulib

Sam James <sam@gentoo.org> writes:

>> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha <libc-alpha@sourceware.org> wrote:
>> I am honestly not sure what to do about this in the long term, but for
>> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
>> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
>> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.  That will
>> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
>> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
>> in order to unblock C23 testing — am I correct?  It doesn’t resolve the
>> larger issue, but it gives us more time to think about what the
>> resolution ought to be.
>> 
>> What do you think?
>
> This is really I think the best option while allowing us time & space
> to complete the larger discussion.
[…]

I am going to go ahead and do this if nobody raises a concrete objection
within the next 24 hours.

zw

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 14:16         ` Zack Weinberg
@ 2022-11-12 17:41           ` Paul Eggert
  2022-11-12 18:50             ` Bruno Haible
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2022-11-12 17:41 UTC (permalink / raw)
  To: Zack Weinberg, Sam James
  Cc: Florian Weimer, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, toolchain, bug-gnulib

On 2022-11-12 06:16, Zack Weinberg wrote:
> I am going to go ahead and do this if nobody raises a concrete objection
> within the next 24 hours.

I object to a simple reversion, as this will cause problems downstream 
with Gnulib-using applications, several of which have already been 
released assuming the current Autoconf git will go into the next 
release, and which will stop working if built from Git with an Autoconf 
2.72 where the AC_SYS_LARGEFILE changes have been reverted. Current 
Gnulib assumes that AC_SYS_LARGEFILE will behave in Autoconf 2.72 like 
what's in Git now. If we change AC_SYS_LARGFILE back, we will need to 
change Gnulib too, and update downstream apps accordingly.

Instead, I suggest a partial reversion, in which AC_SYS_LARGEFILE goes 
back to its previous meaning by default, but there is a well-documented 
way to get the current in-Git meaning, a way that Gnulib can recognize 
and use. For example, you'd get the new meaning if you configure with 
--enable-year2038, or if configure.ac uses a new macro 
AC_SYS_LARGER_FILE that supersedes AC_SYS_LARGEFILE. This will also 
require some Gnulib changes, but they'll be more reliable and stable 
than whipsaw changes required by reverting then whatever future changes 
Autoconf makes.

This proposal would resolve the backward-compatibility concerns for 
people who want to delay worrying about year-2038 issues, while also 
resolving the compatibility concerns of Gnulib. It would also provide a 
better-documented way for distros that want to switch to 64-bit time_t.

Of course this sort of thing cannot be written and tested in an hour. 
But reverting is not that simple either, and would be a less efficient 
use of everybody's time.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  2:20     ` Zack Weinberg
  2022-11-12  3:57       ` Sam James
@ 2022-11-12 18:19       ` Paul Eggert
  1 sibling, 0 replies; 75+ messages in thread
From: Paul Eggert @ 2022-11-12 18:19 UTC (permalink / raw)
  To: Zack Weinberg, Sam James
  Cc: Florian Weimer, libc-alpha, autoconf, c-std-porting, toolchain,
	bug-gnulib

On 2022-11-11 18:20, Zack Weinberg wrote:

> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.

No, I was thinking about libraries as well. Although there are problems 
with libraries and time_t, for decades we've had the same problems with 
AC_SYS_LARGEFILE and off_t, rlim_t, ino_t, etc. Why should time_t be 
treated differently from the other types?


> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)

I can easily understand why glibc didn't take that approach. The LFS API 
designed in the mid-1990s to support both off_t and off64_t in 
user-level code was supposed to be a "transitional API", but we're still 
stuck with it nearly 30 years later, even though almost nobody uses it 
(and the few who do often don't use it correctly). Even if we weren't 
dissuaded by the problems of the LFS API, we won't have a luxury of a 
30-year transition for time_t, as we're only 15 years away from 2038.

More generally, the LFS API approach doesn't scale, as the complexity of 
the implementation would grow exponentially with the number of features 
involved. Nobody wants to implement or support that sort of thing. This 
is why glibc put rlimt_t, ino_t, etc. under the off_t umbrella.


> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038. 

AC_SYS_LARGEFILE doesn't imply AC_SYS_YEAR2038 now, in Autoconf git. 
Things are a bit more complicated, unfortunately.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12  4:20   ` Wookey
  2022-11-12  4:28     ` Sam James
@ 2022-11-12 18:33     ` Paul Eggert
  1 sibling, 0 replies; 75+ messages in thread
From: Paul Eggert @ 2022-11-12 18:33 UTC (permalink / raw)
  To: Wookey, Florian Weimer
  Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Frederic Berat, Arnd Bergmann, Helmut Grohne

On 2022-11-11 20:20, Wookey wrote:
> It doesn't seem right to me that AC_SYS_LARGEFILE should imply
> AC_SYS_YEAR2038. What is the reasoning behind that?

First, in Autoconf git AC_SYS_LARGEFILE does not imply AC_SYS_YEAR2038. 
The former is willing to fall back on 32-bit time_t if 64-bit is not 
available. The latter errors out unless 64-bit time_t is available.

Second and to answer your question, the intent of AC_SYS_LARGEFILE has 
always been, "I want open, stat, lseek, etc. to work on all files, and I 
don't want them to fail with errno==EOVERFLOW simply because my integer 
types are too narrow".

For this to work with glibc 2.34+ on x64 and arm GNU/Linux, time_t must 
be 64 bits just as off_t, dev_t etc must be 64 bits; otherwise syscalls 
like 'stat' stop working on some files. These failures can have security 
implications. Many software developers, even in the security arena, 
haven't thought through the implications of EOVERFLOW and their programs 
do the wrong thing with EOVERFLOW.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 17:41           ` Paul Eggert
@ 2022-11-12 18:50             ` Bruno Haible
  2022-11-12 19:15               ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Bruno Haible @ 2022-11-12 18:50 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Zack Weinberg, Sam James, Florian Weimer,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	toolchain, bug-gnulib

Paul Eggert wrote:
> On 2022-11-12 06:16, Zack Weinberg wrote:
> > I am going to go ahead and do this if nobody raises a concrete objection
> > within the next 24 hours.
> 
> I object to a simple reversion, as this will cause problems downstream 
> with Gnulib-using applications, several of which have already been 
> released assuming the current Autoconf git will go into the next 
> release, and which will stop working if built from Git with an Autoconf 
> 2.72 where the AC_SYS_LARGEFILE changes have been reverted.

Paul, my assessment of Zack's proposed change is different. Things will
not "stop working". But rather, for packages
  * that have been released in the last three months, with the then-newest
    Gnulib,
  * only when this package is reconfigured with Autoconf 2.72
then
  (1) a portability problem to HP-UX/ia64 in 32-bit mode will appear,
  (2) year 2038 compliance measures will not be enabled.

(1) is not something we need to worry about, since HP-UX/ia64 has so few
users, and why should them run 'autoreconf'.

(2) is a tiny setback on our journey to year 2038 compliance. I'm saying
"tiny" because we are still 15 years away, and new releases of the (not
many) affected packages are likely to come in the next 1-2 years.

My assessment is based on the understanding that Zack's proposed change
is essentially

diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 0a9adba5..649d2d17 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -278,7 +278,7 @@ AS_IF([test "$enable_largefile" != no],
          [Define for large files, on AIX-style hosts.],
          [_AC_SYS_LARGEFILE_TEST_INCLUDES])],
     [64],
-      [_AC_SYS_YEAR2038()])])
+      [])])
 
   AH_VERBATIM([__MINGW_USE_VC2005_COMPAT],
 [#if !defined __MINGW_USE_VC2005_COMPAT && defined __MINGW32__

and upon inspection of the largefile.m4 part of this Gnulib commit:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=b9bf95fd0a6ab666b484b1e224321664f051f7fa

Bruno




^ permalink raw reply related	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 18:50             ` Bruno Haible
@ 2022-11-12 19:15               ` Paul Eggert
  2022-11-12 20:23                 ` Wookey
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2022-11-12 19:15 UTC (permalink / raw)
  To: Bruno Haible
  Cc: Zack Weinberg, Sam James, Florian Weimer,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	toolchain, bug-gnulib

On 2022-11-12 10:50, Bruno Haible wrote:
> I'm saying
> "tiny" because we are still 15 years away, and new releases of the (not
> many) affected packages are likely to come in the next 1-2 years.

Not so "tiny", I'm afraid. My department is still running a server with 
libraries and executables that are over 17 years old. I have asked for 
it to be decommissioned, but there are backward compatibility concerns. 
(The OS is still supported by its supplier, and we install security 
patches, most recently the day before yesterday.)

Admittedly my situation differs from embedded environments where 
_TIME_BITS=64 is likely to make a difference 15 years from now. 
Unfortunately the situation in embedded environments is often worse.


> My assessment is based on the understanding that Zack's proposed change
> is essentially [a small change to the code]

Yes, that's my understanding too. Unfortunately the Autoconf change 
would have to be more complicated than that, since documentation and 
comments would have to change accordingly. And the change to Gnulib code 
would be considerably more complicated; this inevitably follows from any 
significant change we make in this area to Autoconf on Savannah. I would 
rather we spent our limited resources moving forward not backward.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 19:15               ` Paul Eggert
@ 2022-11-12 20:23                 ` Wookey
  2022-11-12 20:54                   ` Russ Allbery
  2022-11-12 21:31                   ` Paul Eggert
  0 siblings, 2 replies; 75+ messages in thread
From: Wookey @ 2022-11-12 20:23 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Bruno Haible, Zack Weinberg, Sam James, Florian Weimer,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	toolchain, bug-gnulib, Arnd Bergmann

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

On 2022-11-12 11:15 -0800, Paul Eggert wrote:
> On 2022-11-12 10:50, Bruno Haible wrote:
> > I'm saying
> > "tiny" because we are still 15 years away, and new releases of the (not
> > many) affected packages are likely to come in the next 1-2 years.
> 
> Not so "tiny", I'm afraid. My department is still running a server with
> libraries and executables that are over 17 years old.

Nobody disagrees with the idea that 2038 fixes are now fairly urgent
if we want to avoid real-world stuff breaking in 15 years time. That
has been increasingly clear for the last few years.

But the point here is that we need a bit of co-ordination and a plan,
particularly for binary distros. This isn't a minor change that should
just happen to people because there was an autoconf upgrade. Or at
least I don't think it is. My assumption is that if you just turned it
on in random packages as they were uploaded, there would be very
serious (unacceptably bad) breakage - we need to co-ordinate sets of
matching-ABI packages to upgrade together, and the worry is that the
matching set is 'most of the distro'.

Now, I'm not yet sure if just having autoconf 2.72 will actually break
things. AIUI, these changes only apply where LFS
(-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where
that is not the default on 32bit arches, maybe this is OK. But
probably quite a lot of packages already enable LFS so they are
suddenly going to get a new ABI if they expose timet anywhere?
https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows
163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is
used by a lot of packages (as you might expect - this transition has
been going on for many years). And just having that macro in
configure.(in|ac) will turn 64-bit timet on if you autoreconf with
2.72. Right?

We can't embark on that until we decide whether this transition will
be done within the existing arch/triplet or with a new one. I agree we
should decide that pronto. And I think that 'we' is bigger than just Debian.

If new autoconf (and gnulib) just turns this on within the existing
arch/triplet then we, the distro, can't use those new versions unless
we back out those changes, or until we decide that we are going to
attempt this ABI transition within the existing arch/triplet.

I'm OK with this being done either way (complicated transition within
arch/triplet, or whole-world rebuild with new arch/triplet) once the
size of the problem (and thus the amount of work) is reasonably
understood and there is some consensus amongst distros. TTBOMK we need
some more research before we can make that choice (although I realise
some others are further down this road than I am, and yes I did plan
to get to this point about a year ago, so apologies for
slowness). Hence my suggestion of a full discussion on the
cross-distro list. It is overdue.

However my limited understanding as of right now says that autoconf
2.72 tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72
can't be used in debian yet. So I currently favour not tying them
together in this release.

People have been using AC_SYS_LARGEFILE without 64bit time_t for many
years now so it's not yet clear to me why that cannot continue. And
even if it is a good idea to complete both transitions in the same
upheaval we can't just have everyone who enabled LFS sometime in the
last 20 years suddenly being forced into the time_t change (can we?).

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 20:23                 ` Wookey
@ 2022-11-12 20:54                   ` Russ Allbery
  2022-11-12 21:31                   ` Paul Eggert
  1 sibling, 0 replies; 75+ messages in thread
From: Russ Allbery @ 2022-11-12 20:54 UTC (permalink / raw)
  To: Wookey
  Cc: Paul Eggert, Bruno Haible, Zack Weinberg, Sam James,
	Florian Weimer, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, toolchain, bug-gnulib, Arnd Bergmann

Wookey <wookey@wookware.org> writes:

> Now, I'm not yet sure if just having autoconf 2.72 will actually break
> things. AIUI, these changes only apply where LFS
> (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that
> is not the default on 32bit arches, maybe this is OK. But probably quite
> a lot of packages already enable LFS so they are suddenly going to get a
> new ABI if they expose timet anywhere?
> https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows
> 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is
> used by a lot of packages (as you might expect - this transition has
> been going on for many years). And just having that macro in
> configure.(in|ac) will turn 64-bit timet on if you autoreconf with
> 2.72. Right?

If indeed pre-existing use of AC_SYS_LARGEFILES would suddenly enable
64-bit time_t on autoreconf, I can name two packages just off the top of
my head that this change to Autoconf will immediately break if their
Debian packages are rebuilt with a newer version of Autoconf, creating
severe bugs.

libremctl will have its ABI changed without any coordination or versioning
(which I will be doing, moving forward, but have not started tackling yet
in part because I was waiting to see what the plan would be and whether
there will be some coordinated change to SONAMEs, a new architecture, or
what).  And INN, which admittedly is a disaster about things like this for
lots of historical reasons, will have its *on-disk file format* changed
without notice in a way that will cause serious failure and possibly data
corruption on upgrades.

This is just wildly backward-incompatible and seems like an awful idea.
If we're going to throw a big switch and rebuild everything, it needs to
be done at a distro-wide level.  I believe the only safe thing for
Autoconf to do is to provide an opt-in facility, similar to what was done
for AC_SYS_LARGEFILE, and then leave deciding whether to opt in to
higher-level machinery.

> However my limited understanding as of right now says that autoconf 2.72
> tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be
> used in debian yet. So I currently favour not tying them together in
> this release.

That's also my understanding from the thread so far, although I'm not sure
that I'm following all of the subtleties.

> People have been using AC_SYS_LARGEFILE without 64bit time_t for many
> years now so it's not yet clear to me why that cannot continue.

And these are conceptually not at all the same thing.  I saw Paul's
explanation for why he views them as fundamentally the same because of
their effect on system calls like stat, but I certainly don't think of
them that way and I am quite dubious many other people will either.  The
set of things that I have to check to ensure that time_t is handled
correctly is totally different than the set of things I thought about when
enabling AC_SYS_LARGEFILE many years in the past.

I recognize that there will be overlap once file timestamps are past 2038
and that will happen sooner than anyone plans for, but it's still true
that this has *not* happened right now and this therefore is not currently
creating many bugs, whereas this switch in this way will create many, very
serious bugs immediately.

-- 
Russ Allbery (eagle@eyrie.org)             <https://www.eyrie.org/~eagle/>

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 20:23                 ` Wookey
  2022-11-12 20:54                   ` Russ Allbery
@ 2022-11-12 21:31                   ` Paul Eggert
       [not found]                     ` <951fc967-042c-4978-bd78-8bc4c8706b18@app.fastmail.com>
  2022-11-15  5:09                     ` On time64 and Large File Support Sam James
  1 sibling, 2 replies; 75+ messages in thread
From: Paul Eggert @ 2022-11-12 21:31 UTC (permalink / raw)
  To: Wookey
  Cc: Bruno Haible, Zack Weinberg, Sam James, Florian Weimer,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	toolchain, bug-gnulib, Arnd Bergmann

On 2022-11-12 12:23, Wookey wrote:
> we can't just have everyone who enabled LFS sometime in the
> last 20 years suddenly being forced into the time_t change (can we?)

We've done it in the past.

AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to 
Autoconf. Originally it affected only off_t; its effect on other types 
like ino_t came later. Hence people who initially used AC_SYS_LARGEFILE 
were later "suddenly forced" into an ino_t width change. Similarly for 
other non-off_t types that AC_SYS_LARGEFILE affects.

So there's longstanding precedent for AC_SYS_LARGEFILE changing the 
width of system types that were formerly unaffected. The difference is 
that time_t is more widely used than ino_t etc., and people are 
understandably more concerned about time_t changes.


Because of the concerns raised in this thread it's become clear that 
what's in Autoconf now is too drastic, and I've proposed (though not yet 
implemented) a change that will cause AC_SYS_LARGEFILE to continue to 
not affect time_t unless there's an affirmative request like 
"./configure --enable-year2038". I am waiting for feedback on that from 
Zack and others, and am hoping for quick turnaround on this because we 
do need a new Autoconf release.


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
       [not found]                     ` <951fc967-042c-4978-bd78-8bc4c8706b18@app.fastmail.com>
@ 2022-11-13  5:11                       ` Zack Weinberg
  2022-11-15  5:06                         ` Sam James
  2022-12-25 19:19                         ` Paul Eggert
  0 siblings, 2 replies; 75+ messages in thread
From: Zack Weinberg @ 2022-11-13  5:11 UTC (permalink / raw)
  To: autoconf-patches, c-std-porting; +Cc: Paul Eggert, Florian Weimer, sam, wookey

On Sat, Nov 12, 2022, at 4:33 PM, Zack Weinberg wrote:
> On Sat, Nov 12, 2022, at 4:31 PM, Paul Eggert wrote:
>> Because of the concerns raised in this thread it's become clear that 
>> what's in Autoconf now is too drastic, and I've proposed (though not yet 
>> implemented) a change that will cause AC_SYS_LARGEFILE to continue to 
>> not affect time_t unless there's an affirmative request like 
>> "./configure --enable-year2038".
>
> I am tinkering with an implementation of this right now; more in a couple hours.

"A couple hours" more like eight, ugh.

I have not pushed this, and have only tested it lightly on a current Linux.  It needs testing on weird old systems, particularly old AIX, HP-UX, MinGW.

I don't think a 2.72 release tomorrow is realistic anymore.  The soonest after that I will be able to do one is next weekend, but that should give people time to experiment with this.

zw

-- git format-patch output follows --
From 71dfb135e6874c45f174d7fbd556e5faeb00aced Mon Sep 17 00:00:00 2001
From: Zack Weinberg <zack@owlfolio.org>
Date: Sat, 12 Nov 2022 23:39:25 -0500
Subject: [PATCH] =?UTF-8?q?AC=5FSYS=5FLARGEFILE:=20Don=E2=80=99t=20enlarge?=
 =?UTF-8?q?=20time=5Ft=20by=20default.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Having AC_SYS_LARGEFILE enlarge time_t means that any program that has
already requested large file support will be abruptly migrated to
64-bit time_t (on 32-bit systems) as soon as its configure script is
regenerated with a sufficiently new Autoconf.  We’ve received reports
of several widely used programs and libraries that are not prepared
for this migration, with breakage ranging from annoying (garbage
timestamps in messages) through serious (binary compatibility break
in security-critical shared library) to catastrophic (on-disk data
corruption).

Partially revert f6657256a37da44c987c04bf9cd75575dfca3b60: in the
absence of AC_SYS_YEAR2038, AC_SYS_LARGEFILE will now only add an
--enable-year2038 command line option to configure.  If this option is
used, time_t will be enlarged, allowing people to experiment with the
migration without needing to *edit* the configure script in question,
only regenerate it.

In the process, AC_SYS_LARGEFILE and AC_SYS_YEAR2038 were drastically
overhauled for modularity; it should now be much easier to add support
for platforms that offer large off_t / time_t but not with the standard
feature selection macros.  Also, new macros AC_SYS_LARGEFILE_REQUIRED and
AC_SYS_YEAR2038_REQUIRED can be used by programs for which large off_t /
time_t are essential.

The implementation is a little messy because it needs to gracefully
handle the case where AC_SYS_LARGEFILE and AC_SYS_LARGEFILE_REQUIRED
are both used in the same configure script — or, probably more common,
AC_SYS_LARGEFILE (which invokes _AC_SYS_YEAR2038_OPT_IN) followed by
AC_SYS_YEAR2038 — but if macro B is invoked after macro A, there’s no
way for B to change *what macro A expanded to*.  The best kludge I
managed to find is to AC_CONFIG_COMMANDS_PRE as a m4-level hook that
sets shell variables in an early diversion.

* lib/autoconf/functions.m4 (AC_FUNC_FSEEKO): Rewrite to avoid dependency
  on internal subroutines of AC_SYS_LARGEFILE.

* lib/autoconf/specific.m4 (_AC_SYS_YEAR2038_TEST_INCLUDES): Renamed to
  _AC_SYS_YEAR2038_TEST_CODE.
  (_AC_SYS_YEAR2038): Refactor into subroutines: _AC_SYS_YEAR2038_OPTIONS,
  _AC_SYS_YEAR2038_PROBE, _AC_SYS_YEAR2038_ENABLE.
  (AC_SYS_YEAR2038): Update for refactoring.
  (_AC_SYS_YEAR2038_OPT_IN): New sorta-top-level macro, for use by
  AC_SYS_LARGEFILE, that probes for large time_t only if the
  --enable-year2038 option is given.
  (AC_SYS_YEAR2038_REQUIRED): New top-level macro that insists on
  support for large time_t.

  (_AC_SYS_LARGEFILE_TEST_INCLUDES): Renamed to _AC_SYS_LARGEFILE_TEST_CODE.
  (_AC_SYS_LARGEFILE_MACRO_VALUE, AC_SYS_LARGEFILE): Refactor along same
  lines as above: _AC_SYS_LARGEFILE_OPTIONS, _AC_SYS_LARGEFILE_PROBE,
  _AC_SYS_LARGEFILE_ENABLE.  Invoke _AC_SYS_YEAR2038_OPT_IN at end of
  _AC_SYS_LARGEFILE_PROBE.  MinGW-specific logic moved to YEAR2038
  macros as it has nothing to do with large file support.
  (AC_SYS_LARGEFILE_REQUIRED): New top-level macro that insists on
  support for large off_t.

* tests/local.at (_AT_CHECK_ENV): Also allow changes in CPPFLAGS,
  enableval, enable_*, withval, with_*.

* doc/autoconf.texi, NEWS: Update documentation to match above changes.
  Fix typo in definition of @dvarv.
---
 NEWS                      |  34 ++-
 doc/autoconf.texi         | 159 +++++++++-----
 lib/autoconf/functions.m4 |  66 ++++--
 lib/autoconf/specific.m4  | 429 ++++++++++++++++++++++++--------------
 tests/local.at            |   5 +-
 5 files changed, 456 insertions(+), 237 deletions(-)

diff --git a/NEWS b/NEWS
index 7223fed6..b0b63373 100644
--- a/NEWS
+++ b/NEWS
@@ -21,15 +21,43 @@ GNU Autoconf NEWS - User visible changes.
   that you will get a confusing error message if you run autoconf on
   a configure.ac that neglects to use AC_INIT or AC_OUTPUT.
 
-*** AC_SYS_LARGEFILE now arranges for 64-bit time_t if possible.
-
 *** m4sh diversions like BINSH have been renumbered.
   This matters only for uses that, contrary to the documentation
   and despite warnings, use m4_divert with numbered diversions.
 
 ** New features
 
-*** New macro AC_SYS_YEAR2038 for 64-bit time_t.
+*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
+  These macros attempt to enlarge time_t to 64 bits, on systems where
+  it has historically been only 32 bits wide, and therefore (assuming
+  the usual Unix epoch) cannot represent dates after mid-January of
+  2038 (hence the names).  The difference between the two is that
+  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
+  out if 64-bit time_t is not available.
+
+  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.
+
+  Library authors should be cautious about adding these macros to
+  their configure scripts; they can break binary backward compatibility.
+
+*** New macro AC_SYS_LARGEFILE_REQUIRED.
+  This macro is the same as the existing AC_SYS_LARGEFILE except that
+  it will cause 'configure' to error out if 64-bit off_t is not available,
+  and it does not provide a --disable-largefile option.
+
+*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
+  As an experimental measure to make it easier to rebuild old programs
+  with support for dates after Jan 2038, if you regenerate any configure
+  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
+  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
+  program is configured with this option, time_t will be enlarged if
+  possible, as if AC_SYS_YEAR2038 had been used.
+
+  Using this option in a library build also potentially breaks binary
+  backward compatibility.
 
 ** Obsolete features and new warnings
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7ae8ca64..e45827f0 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -31,7 +31,7 @@
 @c Same as @dvar{ARG, DEFAULT-VAR}, but with @var instead of @samp
 @c around DEFAULT-VAR.
 @macro dvarv{varname, default}
-@r{[}@var{\varname\} = @var{\default\}@r{]}@c
+@r{[}@var{\varname\} = @var{\default\}@r{]}
 @end macro
 
 @c Handling the indexes with Texinfo yields several different problems.
@@ -5229,6 +5229,7 @@ Particular Functions
 @code{ac_cv_func_vfork} variables.
 @end defmac
 
+@anchor{AC_FUNC_FSEEKO}
 @defmac AC_FUNC_FSEEKO
 @acindex{FUNC_FSEEKO}
 @cvindex _LARGEFILE_SOURCE
@@ -5238,12 +5239,13 @@ Particular Functions
 @c @fuindex ftello
 @prindex @code{ftello}
 @c @caindex sys_largefile_source
-If the @code{fseeko} function is available, define @code{HAVE_FSEEKO}.
-Define @code{_LARGEFILE_SOURCE} if necessary to make the prototype
-visible on some systems (e.g., glibc 2.2).  Otherwise linkage problems
-may occur when compiling with @code{AC_SYS_LARGEFILE} on
-largefile-sensitive systems where @code{off_t} does not default to a
-64bit entity.  All systems with @code{fseeko} also supply @code{ftello}.
+If the @code{fseeko} and @code{ftello} functions are available, define
+@code{HAVE_FSEEKO}.  Define @code{_LARGEFILE_SOURCE} if necessary to
+make the prototype visible.
+
+Configure scripts that use @code{AC_FUNC_FSEEKO} should normally also
+use @code{AC_SYS_LARGEFILE} to ensure that @code{off_t} can represent
+all supported file sizes.  @xref{AC_SYS_LARGEFILE}.
 
 The Gnulib module @code{fseeko} invokes @code{AC_FUNC_FSEEKO}
 and also contains workarounds for other portability problems of
@@ -8792,45 +8794,76 @@ System Services
 if the system supports @samp{#!}, @samp{no} if not.
 @end defmac
 
+@anchor{AC_SYS_LARGEFILE}
 @defmac AC_SYS_LARGEFILE
 @acindex{SYS_LARGEFILE}
 @cvindex _FILE_OFFSET_BITS
-@cvindex _LARGE_FILES
-@cvindex _TIME_BITS
 @ovindex CC
 @cindex Large file support
 @cindex LFS
-Arrange for 64-bit file offsets, known as
-@uref{http://@/www.unix.org/@/version2/@/whatsnew/@/lfs20mar.html,
-large-file support}, along with other large attributes.
-On some hosts, one must use special compiler options
-to build programs that can access files with large sizes inode
-numbers, timestamps, or other attributes.  Append any such
-options to the output variable @code{CC}.  Define
-@code{_FILE_OFFSET_BITS}, @code{_LARGE_FILES}, and @code{_TIME_BITS}
-if necessary.
+If the default @code{off_t} type is a 32-bit integer, and therefore
+cannot be used to work with files larger than 4 gigabytes, arrange to
+make a larger @code{off_t} available, if the system supports this.
+Several other types related to the sizes of files and file systems will
+also be enlarged: @code{ino_t}, @code{blkcnt_t}, @code{fsblkcnt_t},
+@code{fsfilcnt_t}, and possibly @code{dev_t}.
+
+If a large @code{off_t} is available (whether or not any arrangements
+were necessary), the shell variable @code{ac_have_largefile} will be set
+to @samp{yes}; if not, it will be set to @samp{no}.
+
+Preprocessor macros will be defined if necessary to make a larger
+@code{off_t} available.  (For example, on many systems the macro
+@code{_FILE_OFFSET_BITS} will be defined.)  Some of these macros only
+work if they are defined before the first system header is included;
+therefore, when using this macro in concert with
+@code{AC_CONFIG_HEADERS}, make sure that @file{config.h} is included
+before any system headers.
+
+On a few older systems, the output variable @code{CC} will also be
+changed to add special compiler options that are needed to enable large
+@code{off_t}.
 
 Large-file support can be disabled by configuring with the
-@option{--disable-largefile} option.  If you disable large-file
-support, your program may have trouble accessing arbitrary files, such
-as files that might be found in an adversary's directory.
+@option{--disable-largefile} option.  Note that this has no effect on
+systems where @code{off_t} is 64 bits or larger by default.  Disabling
+large-file support can have surprising effects, such as causing
+functions like @code{readdir} and @code{stat} to fail on small files
+(because their @emph{inode numbers} are unrepresentable).
 
-If you use this macro, check that your program works even when the types
-@code{blkcnt_t}, @code{dev_t}, @code{ino_t}, @code{off_t}, and @code{time_t}
-are wider than @code{long int}, since this is common when
-large-file support is enabled.  For example, it is not correct to print
-an arbitrary @code{off_t} value @code{X} with @code{printf ("%ld",
-(long int) X)}.  Also, when using this macro in concert with
-@code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is included
-before any system header.
+Regardless of whether you use this macro, portable programs should not
+assume that any of the types listed above fit into a @code{long int}.
+For example, it is not correct to print an arbitrary @code{off_t} value
+@code{X} with @code{printf ("%ld", (long int) X)}.
 
-The LFS introduced the @code{fseeko} and @code{ftello} functions to
-replace their C counterparts @code{fseek} and @code{ftell} that do not
-use @code{off_t}.  Take care to use @code{AC_FUNC_FSEEKO} to make their
-prototypes available when using them and large-file support is
-enabled.
+Note that the standard C library functions @code{fseek} and @code{ftell}
+do not use @code{off_t}.  If you need to use either of these functions,
+you should use @code{AC_FUNC_FSEEKO} as well as @code{AC_SYS_LARGEFILE},
+and then use their Posix replacements @code{fseeko} and @code{ftello},
+which @emph{do} use @code{off_t}, when available.  @xref{AC_FUNC_FSEEKO}.
+
+As of Autoconf 2.72, @code{AC_SYS_LARGEFILE} also @emph{optionally}
+arranges to enlarge @code{time_t}.  This is to make it easier to build
+programs that support timestamps after 2038; many configure scripts will
+not need to be modified, only regenerated with newer Autoconf.  When
+@code{AC_SYS_LARGEFILE} is used, and @code{AC_SYS_YEAR2038} is
+@emph{not} used, @code{time_t} will normally be left at the system's
+default size, but you can request it be enlarged by configuring with the
+@option{--enable-year2038} option.  (When @code{AC_SYS_YEAR2038} is also
+used, @code{time_t} is enlarged if possible.  @xref{AC_SYS_YEAR2038}.)
 @end defmac
 
+@defmac AC_SYS_LARGEFILE_REQUIRED
+@acindex{SYS_LARGEFILE_REQUIRED}
+This macro has the same effect as @code{AC_SYS_LARGEFILE},
+but also declares that the program being configured
+@emph{requires} support for large files.
+If a large @code{off_t} is unavailable,
+@command{configure} will error out.
+The @option{--disable-largefile} option will not be available.
+@end defmac
+
+
 @anchor{AC_SYS_LONG_FILE_NAMES}
 @defmac AC_SYS_LONG_FILE_NAMES
 @acindex{SYS_LONG_FILE_NAMES}
@@ -8849,32 +8882,58 @@ System Services
 @samp{yes}.  If not, set the variable to @samp{no}.
 @end defmac
 
+@anchor{AC_SYS_YEAR2038}
 @defmac AC_SYS_YEAR2038
 @acindex{SYS_YEAR2038}
 @cvindex _TIME_BITS
-@ovindex CC
 @cindex Year 2038
-If the default @code{time_t} type is a signed 32-bit integer that stops
-working in the year 2038, then arrange to use a wider @code{time_t} if
-possible and report a fatal error otherwise.  Define @code{_TIME_BITS}
-if necessary.
+If the default @code{time_t} type is a signed 32-bit integer,
+and therefore (assuming the usual Unix epoch) cannot represent
+timestamps after mid-January of 2038, arrange to make a larger
+@code{time_t} available, if the system supports this.
 
-Wider-time support can be disabled by configuring with the
-@option{--disable-year2038} option.
+If a large @code{time_t} is available (whether or not any arrangements
+were necessary), the shell variable @code{ac_have_year2038} will be set
+to @samp{yes}; if not, it will be set to @samp{no}.
+
+Preprocessor macros will be defined if necessary to make a larger
+@code{time_t} available.  (For example, on some systems the macro
+@code{_TIME_BITS} will be defined.)  Some of these macros only work if
+they are defined before the first system header is included; therefore,
+when using this macro in concert with @code{AC_CONFIG_HEADERS}, make
+sure that @file{config.h} is included before any system headers.
+
+Support for timestamps after 2038 can be disabled by configuring with
+the @option{--disable-year2038} option.  Note that this has no effect on
+systems where @code{time_t} is 64 bits or larger by default.
+If this option is @emph{not} given, and @command{configure} fails to
+find a way to enable a large @code{time_t}, but inspection of the
+system suggests that this feature is available @emph{somehow}, it will
+error out.
 
 Regardless of whether you use this macro, portable programs should not
 assume that @code{time_t} fits into @code{long int}.  For example, it is
 not correct to print an arbitrary @code{time_t} value @code{X} with
-@code{printf ("%ld", (long int) X)}.  Also, when using this macro in
-concert with @code{AC_CONFIG_HEADERS}, be sure that @file{config.h} is
-included before any system header.
+@code{printf ("%ld", (long int) X)}.
 
-@code{AC_SYS_LARGFILE} also widens @code{time_t} if possible,
-as this is needed for programs that access files with large timestamps,
-However, @code{AC_SYS_LARGEFILE} merely warns if @code{time_t} is too
-narrow and cannot be widened, rather than reporting a fatal error as
-@code{AC_SYS_YEAR2038} does.  This is for portability to older
-platforms that will become obsolete in the year 2038.
+@strong{Caution:} If you are developing a shared library, and
+@code{time_t} appears anywhere in your library's public interface, use
+of this macro may break binary compatibility with older executables.
+@end defmac
+
+@defmac AC_SYS_YEAR2038_REQUIRED
+@acindex{SYS_YEAR2038_REQUIRED}
+This macro has the same effect as @code{AC_SYS_YEAR2038},
+but also declares that the program being configured
+@emph{requires} support for timestamps after mid-January of 2038.
+If a large @code{time_t} is unavailable,
+@command{configure} will @emph{unconditionally} error out
+(unlike the behavior of @code{AC_SYS_YEAR2038}).
+The @option{--disable-year2038} option will not be available.
+
+@strong{Caution:} If you are developing a shared library, and
+@code{time_t} appears anywhere in your library's public interface, use
+of this macro may break binary compatibility with older executables.
 @end defmac
 
 @node C and Posix Variants
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index de01f74a..adbc86d8 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -641,35 +641,57 @@ AU_ALIAS([AM_FUNC_FNMATCH], [AC_FUNC_FNMATCH])
 AU_ALIAS([fp_FUNC_FNMATCH], [AC_FUNC_FNMATCH])
 
 
+# _AC_FUNC_FSEEKO_TEST_PROGRAM
+# ----------------------------
+# Test code used by AC_FUNC_FSEEKO.
+m4_define([_AC_FUNC_FSEEKO_TEST_PROGRAM],
+[AC_LANG_PROGRAM([[
+#if defined __hpux && !defined _LARGEFILE_SOURCE
+# include <limits.h>
+# if LONG_MAX >> 31 == 0
+#  error "32-bit HP-UX 11/ia64 needs _LARGEFILE_SOURCE for fseeko in C++"
+# endif
+#endif
+#include <sys/types.h> /* for off_t */
+#include <stdio.h>
+]], [[
+  int (*fp1) (FILE *, off_t, int) = fseeko;
+  off_t (*fp2) (FILE *) = ftello;
+  return fseeko (stdin, 0, 0)
+      && fp1 (stdin, 0, 0)
+      && ftello (stdin) >= 0
+      && fp2 (stdin) >= 0;
+]])])
+
 # AC_FUNC_FSEEKO
 # --------------
+# Check for correctly prototyped declarations of fseeko and ftello;
+# define HAVE_FSEEKO if they are available.  If it is necessary to
+# define _LARGEFILE_SOURCE=1 to make these declarations available,
+# do that (this is needed on 32-bit HP/UX).  We used to try defining
+# _XOPEN_SOURCE=500 too, to work around a bug in glibc 2.1.3, but that
+# breaks too many other things.  If you want fseeko and ftello with
+# glibc, upgrade to a fixed glibc.
 AN_FUNCTION([ftello], [AC_FUNC_FSEEKO])
 AN_FUNCTION([fseeko], [AC_FUNC_FSEEKO])
 AC_DEFUN([AC_FUNC_FSEEKO],
-[_AC_SYS_LARGEFILE_MACRO_VALUE(_LARGEFILE_SOURCE, 1,
-   [ac_cv_sys_largefile_source],
-   [Define to 1 to make fseeko visible on some hosts (e.g. glibc 2.2).],
-   [[#if defined __hpux && !defined _LARGEFILE_SOURCE
-      #include <limits.h>
-      #if LONG_MAX >> 31 == 0
-       #error "32-bit HP-UX 11/ia64 needs _LARGEFILE_SOURCE for fseeko in C++"
-      #endif
-     #endif
-     #include <sys/types.h> /* for off_t */
-     #include <stdio.h>]],
-   [[int (*fp) (FILE *, off_t, int) = fseeko;
-     return fseeko (stdin, 0, 0) && fp (stdin, 0, 0);]])
-
-# We used to try defining _XOPEN_SOURCE=500 too, to work around a bug
-# in glibc 2.1.3, but that breaks too many other things.
-# If you want fseeko and ftello with glibc, upgrade to a fixed glibc.
-if test $ac_cv_sys_largefile_source != unknown; then
-  AC_DEFINE(HAVE_FSEEKO, 1,
-    [Define to 1 if fseeko (and presumably ftello) exists and is declared.])
-fi
+[AC_CACHE_CHECK([for declarations of fseeko and ftello],
+  [ac_cv_func_fseeko_ftello],
+  [AC_COMPILE_IFELSE([_AC_FUNC_FSEEKO_TEST_PROGRAM],
+    [ac_cv_func_fseeko_ftello=yes],
+    [ac_save_CPPFLAGS="$CPPFLAGS"
+    CPPFLAGS="$CPPFLAGS -D_LARGEFILE_SOURCE=1"
+    AC_COMPILE_IFELSE([_AC_FUNC_FSEEKO_TEST_PROGRAM],
+      [ac_cv_func_fseeko_ftello="need _LARGEFILE_SOURCE"],
+      [ac_cv_func_fseeko_ftello=no])])])
+AS_IF([test "$ac_cv_func_fseeko_ftello" != no],
+  [AC_DEFINE([HAVE_FSEEKO], [1],
+    [Define to 1 if fseeko (and ftello) are declared in stdio.h.])])
+AS_IF([test "$ac_cv_func_fseeko_ftello" = "need _LARGEFILE_SOURCE"],
+  [AC_DEFINE([_LARGEFILE_SOURCE], [1],
+    [Define to 1 if necessary to make fseeko visible.])])
 ])# AC_FUNC_FSEEKO
 
-
 # AC_FUNC_GETGROUPS
 # -----------------
 # Try to find 'getgroups', and check that it works.
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 0a9adba5..73f1444d 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -85,9 +85,13 @@ AU_DEFUN([AC_ARG_ARRAY], [],
 with arguments. Remove this warning when you adjust your code.])
 
 
-# _AC_SYS_YEAR2038_TEST_INCLUDES
-# ------------------------------
-AC_DEFUN([_AC_SYS_YEAR2038_TEST_INCLUDES],
+# _AC_SYS_YEAR2038_TEST_CODE
+# --------------------------
+# C code used to probe for time_t that can represent time points more
+# than 2**31 - 1 seconds after the epoch.  With the usual Unix epoch,
+# these correspond to dates after 2038-01-18 22:14:07 +0000 (Gregorian),
+# hence the name.
+AC_DEFUN([_AC_SYS_YEAR2038_TEST_CODE],
 [[
   #include <time.h>
   /* Check that time_t can represent 2**32 - 1 correctly.  */
@@ -98,102 +102,171 @@ AC_DEFUN([_AC_SYS_YEAR2038_TEST_INCLUDES],
                           ? 1 : -1];
 ]])
 
-# _AC_SYS_YEAR2038(REQUIRE-YEAR2038-SAFE)
-# ---------------------------------------
-AC_DEFUN([_AC_SYS_YEAR2038],
-[
- 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,
-  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
-  dnl   - __time32_t on 32-bit mingw,
-  dnl   - __time64_t on 64-bit mingw and on MSVC (since MSVC 8).
-  dnl But when compiling with -D__MINGW_USE_VC2005_COMPAT, time_t is an
-  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 time_t past the year 2038], [ac_cv_type_time_t_y2038],
-    [AC_COMPILE_IFELSE(
-       [AC_LANG_SOURCE([_AC_SYS_YEAR2038_TEST_INCLUDES])],
-       [ac_cv_type_time_t_y2038=yes], [ac_cv_type_time_t_y2038=no])
-    ])
-  if test "$ac_cv_type_time_t_y2038" = no; then
-    AC_CACHE_CHECK([for 64-bit time_t with _TIME_BITS=64],
-      [ac_cv_type_time_t_bits_macro],
-      [AC_COMPILE_IFELSE(
-         [AC_LANG_SOURCE([[#define _TIME_BITS 64
-                           #define _FILE_OFFSET_BITS 64
-                           ]_AC_SYS_YEAR2038_TEST_INCLUDES])],
-         [ac_cv_type_time_t_bits_macro=yes],
-         [ac_cv_type_time_t_bits_macro=no])
-      ])
-    if test "$ac_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.])
-      ac_cv_type_time_t_y2038=yes
-    fi
-  fi
-  if test $ac_cv_type_time_t_y2038 = no; then
-    AC_COMPILE_IFELSE(
-      [AC_LANG_SOURCE(
-         [[#ifdef _USE_32BIT_TIME_T
-             int ok;
-           #else
-             error fail
-           #endif
-         ]])],
-      [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 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.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 'CC="${CC} -m64"'.
-                   To build with a 32-bit time_t anyway (not recommended),
-                   configure with '--disable-year2038'.]);;
-            esac
-            rm -f conftest.time
-          fi])
-       if test "$ac_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 'CC="${CC} -m64"' perhaps?])
-         ac_warned_about_y2038=yes
-       fi
-      ])
-  fi])
+# _AC_SYS_YEAR2038_OPTIONS
+# ------------------------
+# List of known ways to enable support for large time_t.  If you change
+# this list you probably also need to change the AS_CASE at the end of
+# _AC_SYS_YEAR2038_PROBE.
+m4_define([_AC_SYS_YEAR2038_OPTIONS], m4_normalize(
+    ["none needed"]                   dnl 64-bit and newer 32-bit Unix
+    ["-D_TIME_BITS=64"]               dnl glibc 2.34 with some 32-bit ABIs
+    ["-D__MINGW_USE_VC2005_COMPAT"]   dnl 32-bit MinGW
+    ["-U_USE_32_BIT_TIME_T -D__MINGW_USE_VC2005_COMPAT"]
+                                      dnl 32-bit MinGW (misconfiguration)
+))
+
+# _AC_SYS_YEAR2038_PROBE([IF-NOT-DETECTED])
+# -----------------------------------------
+# Subroutine of AC_SYS_YEAR2038.  Probe for time_t that can represent
+# time points more than 2**31 - 1 seconds after the epoch (dates after
+# 2038-01-18, see above) and set the cache variable ac_cv_sys_year2038_opts
+# to one of the values in the _AC_SYS_YEAR2038_OPTIONS list, or to
+# "support not detected" if none of them worked.  Then, set compilation
+# options and #defines as necessary to enable large time_t support.
+#
+# Note that we do not test whether mktime, localtime, etc. handle
+# large values of time_t correctly, as that would require use of
+# AC_TRY_RUN.  Note also that some systems only support large time_t
+# together with large off_t.
+#
+# If support is not detected, the behavior depends on which of the
+# top-level AC_SYS_YEAR2038 macros was used (see below).
+#
+# If you change this macro you may also need to change
+# _AC_SYS_YEAR2038_OPTIONS.
+AC_DEFUN([_AC_SYS_YEAR2038_PROBE],
+[AC_CACHE_CHECK([for $CC option to enable timestamps after Jan 2038],
+  [ac_cv_sys_year2038_opts],
+  [ac_save_CPPFLAGS="$CPPFLAGS"
+  ac_opt_found=no
+  for ac_opt in _AC_SYS_YEAR2038_OPTIONS; do
+    AS_IF([test x"$ac_opt" != x"none needed"],
+      [CPPFLAGS="$ac_save_CPPFLAGS $ac_opt"])
+    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([_AC_SYS_YEAR2038_TEST_CODE])],
+      [ac_cv_sys_year2038_opts="$ac_opt"
+      ac_opt_found=yes])
+    test $ac_opt_found = no || break
+  done
+  CPPFLAGS="$ac_save_CPPFLAGS"
+  test $ac_opt_found = yes || ac_cv_sys_year2038_opts="support not detected"])
+
+ac_have_year2038=yes
+AS_CASE([$ac_cv_sys_year2038_opts],
+  ["none needed"], [],
+  ["support not detected"],
+    [ac_have_year2038=no
+     AS_CASE([$enable_year2038],
+      [required],
+        [AC_MSG_FAILURE([support for timestamps after Jan 2038 is required])],
+      [yes],
+        [# If we're not cross compiling and 'touch' works with a large
+        # timestamp, then we can presume the system supports wider time_t
+        # *somehow* and we just weren't able to detect it.  One common
+        # case that we deliberately *don't* probe for is a system that
+        # supports both 32- and 64-bit ABIs but only the 64-bit ABI offers
+        # wide time_t.  (It would be inappropriate for us to override an
+        # intentional use of -m32.)  Error out, demanding use of
+        # --disable-year2038 if this is intentional.
+        AS_IF([test $cross_compiling = no],
+          [AS_IF([TZ=UTC0 touch -t 210602070628.15 conftest.time 2>/dev/null],
+            [AS_CASE([`TZ=UTC0 LC_ALL=C ls -l conftest.time 2>/dev/null`],
+              [*'Feb  7  2106'* | *'Feb  7 17:10'*],
+              [AC_MSG_FAILURE(m4_text_wrap(
+      [this system appears to support timestamps after January 2038,
+       but no mechanism for enabling wide 'time_t' was detected.
+       Did you mean to build a 64-bit binary? (e.g. 'CC="${CC} -m64"'.)
+       To proceed with 32-bit time_t, configure with '--disable-year2038'.],
+      [], [], [55]))])])])])],
+
+  ["-D_TIME_BITS=64"],
+    [AC_DEFINE([_TIME_BITS], [64],
+      [Number of bits in time_t, on hosts where this is settable.])],
+
+  ["-D__MINGW_USE_VC2005_COMPAT=1"],
+    [AC_DEFINE([__MINGW_USE_VC2005_COMPAT], [1],
+      [Define to 1 on platforms where this makes time_t a 64-bit type.])],
+
+  ["-U_USE_32_BIT_TIME_T"*],
+    [AC_MSG_FAILURE(m4_text_wrap(
+      [the 'time_t' type is currently forced to be 32-bit.
+       It will stop working after January 2038.
+       Remove _USE_32BIT_TIME_T from the compiler flags.],
+      [], [], [55]))],
+
+  [AC_MSG_ERROR(
+    [internal error: bad value for \$ac_cv_sys_year2038_opts])])
 ])
 
+# _AC_SYS_YEAR2038_ENABLE
+# -----------------------
+# Subroutine of AC_SYS_YEAR2038 and _AC_SYS_YEAR2038_OPT_IN.
+# Depending on which of the YEAR2038 macros was used, add either an
+# --enable-year2038, or a --disable-year2038, or no option at all to
+# the configure script.  Note that 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.
+m4_define([_AC_SYS_YEAR2038_ENABLE],
+[m4_divert_text([DEFAULTS],
+  m4_provide_if([AC_SYS_YEAR2038_REQUIRED],
+    [enable_year2038=required],
+  m4_provide_if([AC_SYS_YEAR2038],
+    [enable_year2038=yes],
+    [enable_year2038=no])))]dnl
+[m4_provide_if([AC_SYS_YEAR2038_REQUIRED], [],
+[AC_ARG_ENABLE([year2038],
+  m4_provide_if([AC_SYS_YEAR2038],
+    [AS_HELP_STRING([--disable-year2038],
+      [omit support for dates after Jan 2038])],
+    [AS_HELP_STRING([--enable-year2038],
+      [include support for dates after Jan 2038])]))])])
+
+# _AC_SYS_YEAR2038_OPT_IN
+# -----------------------
+# If the --enable-year2038 option is given to configure, attempt to
+# detect and activate support for large time_t on 32-bit systems.
+# This macro is automatically invoked by AC_SYS_LARGEFILE when large
+# *file* support is detected.  It does not AC_REQUIRE AC_SYS_LARGEFILE
+# to avoid a dependency loop, and is therefore unsafe to expose as a
+# documented macro.
+AC_DEFUN([_AC_SYS_YEAR2038_OPT_IN],
+[m4_provide_if([_AC_SYS_YEAR2038_PROBE], [], [dnl
+  AS_IF([test "$enable_year2038" != no], [_AC_SYS_YEAR2038_PROBE])
+  AC_CONFIG_COMMANDS_PRE([_AC_SYS_YEAR2038_ENABLE])
+])])
+
+# AC_SYS_YEAR2038
+# ---------------
+# Attempt to detect and activate support for large time_t.
+# On systems where time_t is not always 64 bits, this probe can be
+# skipped by passing the --disable-year2038 option to configure.
 AC_DEFUN([AC_SYS_YEAR2038],
-[
-  _$0([require-year2038-safe])
-])
+[m4_provide_if([AC_SYS_LARGEFILE_REQUIRED], [],
+  [AC_REQUIRE([AC_SYS_LARGEFILE])])]dnl
+[m4_provide_if([_AC_SYS_YEAR2038_PROBE], [], [dnl
+  AS_IF([test "$enable_year2038" != no], [_AC_SYS_YEAR2038_PROBE])
+  AC_CONFIG_COMMANDS_PRE([_AC_SYS_YEAR2038_ENABLE])
+])])
 
+# AC_SYS_YEAR2038_REQUIRED
+# ------------------------
+# Same as AC_SYS_YEAR2038, but declares that this program *requires*
+# support for large time_t.  If we cannot find any way to make time_t
+# capable of representing values larger than 2**31 - 1, configure will
+# error out.  Furthermore, no --enable-year2038 nor --disable-year2038
+# option will be available.
+AC_DEFUN([AC_SYS_YEAR2038_REQUIRED],
+[m4_provide_if([AC_SYS_LARGEFILE_REQUIRED], [],
+  [AC_REQUIRE([AC_SYS_LARGEFILE])])]dnl
+[m4_provide_if([_AC_SYS_YEAR2038_PROBE], [], [dnl
+  _AC_SYS_YEAR2038_PROBE
+  AC_CONFIG_COMMANDS_PRE([_AC_SYS_YEAR2038_ENABLE])
+])])
 
-# _AC_SYS_LARGEFILE_TEST_INCLUDES
-# -------------------------------
-m4_define([_AC_SYS_LARGEFILE_TEST_INCLUDES],
+# _AC_SYS_LARGEFILE_TEST_CODE
+# ---------------------------
+# C code used to probe for large file support.
+m4_define([_AC_SYS_LARGEFILE_TEST_CODE],
 [@%:@include <sys/types.h>
  /* Check that off_t can represent 2**63 - 1 correctly.
     We can't simply define LARGE_OFF_T to be 9223372036854775807,
@@ -205,33 +278,89 @@ m4_define([_AC_SYS_LARGEFILE_TEST_INCLUDES],
 		      ? 1 : -1]];[]dnl
 ])
 
+# _AC_SYS_LARGEFILE_OPTIONS
+# -------------------------
+# List of known ways to enable support for large files.  If you change
+# this list you probably also need to change the AS_CASE at the end of
+# _AC_SYS_LARGEFILE_PROBE.
+m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize(
+    ["none needed"]                   dnl Most current systems
+    ["-D_FILE_OFFSET_BITS=64"]        dnl X/Open LFS spec
+    ["-D_LARGE_FILES=1"]              dnl AIX (which versions?)
+    ["-n32"]                          dnl Irix 6.2 w/ SGI compiler
+))
 
-# _AC_SYS_LARGEFILE_MACRO_VALUE(C-MACRO, VALUE,
-#				CACHE-VAR,
-#				DESCRIPTION,
-#				PROLOGUE, [FUNCTION-BODY])
-# --------------------------------------------------------
-m4_define([_AC_SYS_LARGEFILE_MACRO_VALUE],
-[AC_CACHE_CHECK([for $1 value needed for large files], [$3],
-[while :; do
-  m4_ifval([$6], [AC_LINK_IFELSE], [AC_COMPILE_IFELSE])(
-    [AC_LANG_PROGRAM([$5], [$6])],
-    [$3=no; break])
-  m4_ifval([$6], [AC_LINK_IFELSE], [AC_COMPILE_IFELSE])(
-    [AC_LANG_PROGRAM([#undef $1
-#define $1 $2
-$5], [$6])],
-    [$3=$2; break])
-  $3=unknown
-  break
-done])
-case $$3 in #(
-  no | unknown) ;;
-  *) AC_DEFINE_UNQUOTED([$1], [$$3], [$4]);;
-esac
-rm -rf conftest*[]dnl
-])# _AC_SYS_LARGEFILE_MACRO_VALUE
+# _AC_SYS_LARGEFILE_PROBE
+# -----------------------
+# Subroutine of AC_SYS_LARGEFILE. Probe for large file support and set
+# the cache variable ac_cv_sys_largefile_opts to one of the values in
+# the _AC_SYS_LARGEFILE_OPTIONS list, or to "support not detected" if
+# none of the options in that list worked.  Then, set compilation
+# options and #defines as necessary to enable large file support.
+#
+# If large file support is not detected, the behavior depends on which of
+# the top-level AC_SYS_LARGEFILE macros was used (see below).
+#
+# If you change this macro you may also need to change
+# _AC_SYS_LARGEFILE_OPTIONS.
+AC_DEFUN([_AC_SYS_LARGEFILE_PROBE],
+[AC_CACHE_CHECK([for $CC option to enable large file support],
+  [ac_cv_sys_largefile_opts],
+  [ac_save_CC="$CC"
+  ac_opt_found=no
+  for ac_opt in _AC_SYS_LARGEFILE_OPTIONS; do
+    AS_IF([test x"$ac_opt" != x"none needed"],
+      [CC="$ac_save_CC $ac_opt"])
+    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([_AC_SYS_LARGEFILE_TEST_CODE])],
+      [ac_cv_sys_largefile_opts="$ac_opt"
+      ac_opt_found=yes])
+    test $ac_opt_found = no || break
+  done
+  CC="$ac_save_CC"
+  test $ac_opt_found = yes || ac_cv_sys_largefile_opts="support not detected"])
 
+ac_have_largefile=yes
+AS_CASE([$ac_cv_sys_largefile_opts],
+  ["none needed"], [],
+  ["support not detected"],
+    [ac_have_largefile=no
+     AS_IF([test $enable_largefile = required],
+       [AC_MSG_FAILURE([support for large files is required])])],
+
+  ["-D_FILE_OFFSET_BITS=64"],
+    [AC_DEFINE([_FILE_OFFSET_BITS], [64],
+      [Number of bits in a file offset, on hosts where this is settable.])],
+
+  ["-D_LARGE_FILES=1"],
+    [AC_DEFINE([_LARGE_FILES], [1],
+      [Define to 1 on platforms where this makes off_t a 64-bit type.])],
+
+  ["-n32"],
+    [CC="$CC -n32"],
+
+  [AC_MSG_ERROR(
+    [internal error: bad value for \$ac_cv_sys_largefile_opts])])
+
+_AC_SYS_YEAR2038_OPT_IN
+])
+
+# _AC_SYS_LARGEFILE_ENABLE
+# ------------------------
+# Subroutine of AC_SYS_LARGEFILE.  If AC_SYS_LARGEFILE_REQUIRED was
+# not used at any point in this configure script, add a
+# --disable-largefile option to the configure script.  Note that this
+# is expanded very late and therefore there cannot be any code in the
+# AC_ARG_ENABLE.  The default value for `enable_largefile` is emitted
+# unconditionally because the generated shell code always looks at
+# this variable.
+m4_define([_AC_SYS_LARGEFILE_ENABLE],
+[m4_divert_text([DEFAULTS],
+  m4_provide_if([AC_SYS_LARGEFILE_REQUIRED],
+    [enable_largefile=required],
+    [enable_largefile=yes]))]dnl
+[m4_provide_if([AC_SYS_LARGEFILE_REQUIRED], [],
+[AC_ARG_ENABLE([largefile],
+  [AS_HELP_STRING([--disable-largefile], [omit support for large files])])])])
 
 # AC_SYS_LARGEFILE
 # ----------------
@@ -242,50 +371,28 @@ rm -rf conftest*[]dnl
 # Additionally, on Linux file systems with 64-bit inodes a file that happens
 # to have a 64-bit inode number cannot be accessed by 32-bit applications on
 # Linux x86/x86_64.  This can occur with file systems such as XFS and NFS.
+# This macro allows configuration to continue if the system doesn't support
+# large files; see also AC_SYS_LARGEFILE_REQUIRED.
 AC_DEFUN([AC_SYS_LARGEFILE],
-[AC_ARG_ENABLE(largefile,
-	       [  --disable-largefile     omit support 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
-       ac_save_CC=$CC
-       while :; do
-	 # IRIX 6.2 and later do not support large files by default,
-	 # so use the C compiler's -n32 option if that helps.
-	 AC_LANG_CONFTEST([AC_LANG_PROGRAM([_AC_SYS_LARGEFILE_TEST_INCLUDES])])
-	 AC_COMPILE_IFELSE([], [break])
-	 CC="$CC -n32"
-	 AC_COMPILE_IFELSE([], [ac_cv_sys_largefile_CC=' -n32'; break])
-	 break
-       done
-       CC=$ac_save_CC
-       rm -f conftest.$ac_ext
-    fi])
-  if test "$ac_cv_sys_largefile_CC" != no; then
-    CC=$CC$ac_cv_sys_largefile_CC
-  fi
-
-  _AC_SYS_LARGEFILE_MACRO_VALUE(_FILE_OFFSET_BITS, 64,
-    ac_cv_sys_file_offset_bits,
-    [Number of bits in a file offset, on hosts where this is settable.],
-    [_AC_SYS_LARGEFILE_TEST_INCLUDES])
-  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],
-      [_AC_SYS_YEAR2038()])])
-
-  AH_VERBATIM([__MINGW_USE_VC2005_COMPAT],
-[#if !defined __MINGW_USE_VC2005_COMPAT && defined __MINGW32__
-# define __MINGW_USE_VC2005_COMPAT 1 /* For 64-bit time_t.  */
-#endif])
-])# AC_SYS_LARGEFILE
+[m4_provide_if([_AC_SYS_LARGEFILE_PROBE], [], [dnl
+  AS_IF([test "$enable_largefile" != no], [_AC_SYS_LARGEFILE_PROBE])
+  AC_CONFIG_COMMANDS_PRE([_AC_SYS_LARGEFILE_ENABLE])
+])])
 
+# AC_SYS_LARGEFILE_REQUIRED
+# -------------------------
+# Same as AC_SYS_LARGEFILE, but declares that this program *requires*
+# support for large files.  If we cannot find a combination of compiler
+# options and #defines that makes `off_t` capable of representing 2**63 - 1,
+# `configure` will error out.  Furthermore, `configure` will not offer a
+# --disable-largefile command line option.
+# If both AC_SYS_LARGEFILE and AC_SYS_LARGEFILE_REQUIRED are used in the
+# same configure script -- in either order -- AC_SYS_LARGEFILE_REQUIRED wins.
+AC_DEFUN([AC_SYS_LARGEFILE_REQUIRED],
+[m4_provide_if([_AC_SYS_LARGEFILE_PROBE], [], [dnl
+  _AC_SYS_LARGEFILE_PROBE
+  AC_CONFIG_COMMANDS_PRE([_AC_SYS_LARGEFILE_ENABLE])
+])])
 
 # AC_SYS_LONG_FILE_NAMES
 # ----------------------
diff --git a/tests/local.at b/tests/local.at
index a9cf4050..158ba841 100644
--- a/tests/local.at
+++ b/tests/local.at
@@ -347,6 +347,8 @@ m4_define([AT_CHECK_CONFIGURE],
 #   Set by AC_INIT.
 # - interpval
 #   Set by AC_SYS_INTERPRETER.
+# - enableval, withval, enable_*, with_*
+#   Set by AC_ARG_ENABLE and AC_ARG_WITH.
 # - CONFIG_STATUS and DEFS
 #   Set by AC_OUTPUT.
 # - AC_SUBST'ed variables
@@ -381,7 +383,7 @@ if test -f state-env.before && test -f state-env.after; then
     ($EGREP -v '^(m4_join([|],
       [a[cs]_.*],
       [(exec_)?prefix|DEFS|CONFIG_STATUS],
-      [CC|CFLAGS|CPP|GCC|CXX|CXXFLAGS|CXXCPP|GXX|F77|FFLAGS|FLIBS|G77],
+      [CC|CFLAGS|CPPFLAGS|CPP|GCC|CXX|CXXFLAGS|CXXCPP|GXX|F77|FFLAGS|FLIBS|G77],
       [ERL|ERLC|ERLCFLAGS|ERLANG_PATH_ERL|ERLANG_ROOT_DIR|ERLANG_LIB_DIR],
       [ERLANG_LIB_DIR_.*|ERLANG_LIB_VER_.*|ERLANG_INSTALL_LIB_DIR],
       [ERLANG_INSTALL_LIB_DIR_.*|ERLANG_ERTS_VER|OBJC|OBJCPP|OBJCFLAGS],
@@ -395,6 +397,7 @@ if test -f state-env.before && test -f state-env.after; then
       [X_(CFLAGS|(EXTRA_|PRE_)?LIBS)|x_(includes|libraries)|(have|no)_x],
       [(host|build|target)(_(alias|cpu|vendor|os))?],
       [cross_compiling|U],
+      [enableval|enable_.*|withval|with_.*],
       [interpval|PATH_SEPARATOR],
       [GFC|F77_DUMMY_MAIN|f77_(case|underscore)],
       [FC(_DUMMY_MAIN|FLAGS|LIBS|FLAGS_[fF]|_MODEXT|_MODINC|_MODOUT|_DEFINE)?],
-- 
2.37.2

^ permalink raw reply related	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  9:19 ` Florian Weimer
                     ` (3 preceding siblings ...)
  2022-11-12  4:20   ` Wookey
@ 2022-11-14  8:39   ` Adam Sampson
  2022-11-14 11:47     ` Florian Weimer
  2022-11-14 20:26     ` Arsen Arsenović
  4 siblings, 2 replies; 75+ messages in thread
From: Adam Sampson @ 2022-11-14  8:39 UTC (permalink / raw)
  To: Florian Weimer via Libc-alpha
  Cc: Sam James, Florian Weimer, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, Frederic Berat

Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:

> We should define new target triplets for this if it's really required.

If the consensus on this does come down to the definition of new
architecture triplets, are there any other changes that should (or
could) be made at the same time, beyond time64 and LFS?

Thanks,

-- 
Adam Sampson <ats@offog.org>                         <http://offog.org/>

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-14  8:39   ` Adam Sampson
@ 2022-11-14 11:47     ` Florian Weimer
  2022-11-14 20:26     ` Arsen Arsenović
  1 sibling, 0 replies; 75+ messages in thread
From: Florian Weimer @ 2022-11-14 11:47 UTC (permalink / raw)
  To: Adam Sampson via Libc-alpha
  Cc: Adam Sampson, Sam James, autoconf, c-std-porting, Zack Weinberg,
	David Seifert, Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, Frederic Berat

* Adam Sampson via Libc-alpha:

> Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> We should define new target triplets for this if it's really required.
>
> If the consensus on this does come down to the definition of new
> architecture triplets, are there any other changes that should (or
> could) be made at the same time, beyond time64 and LFS?

I don't think there are any other non-controversial changes for
i386-linux-gnu (relative to the current i386-linux-gnu interpretation,
i.e. with SSE2 stack alignment).  Lots and lots of glibc compat symbols
will be dropped, but that should be a transparent change (and something
you would be exposed through mere recompilation against current glibc).

It seems it would be an opportunity to clean up the Arm triplets and
define the ISAs/ABIs for the new ones more tightly than what's been
previously used.  But I have zero insight into which ISAs/ABIs would be
required.

I don't know if any of the legacy 32-bit ABIs would benefit from similar
clarification.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-14  8:39   ` Adam Sampson
  2022-11-14 11:47     ` Florian Weimer
@ 2022-11-14 20:26     ` Arsen Arsenović
  2022-11-14 20:52       ` Florian Weimer
  1 sibling, 1 reply; 75+ messages in thread
From: Arsen Arsenović @ 2022-11-14 20:26 UTC (permalink / raw)
  To: Adam Sampson
  Cc: Florian Weimer via Libc-alpha, Sam James, Florian Weimer,
	autoconf, c-std-porting, Zack Weinberg, David Seifert,
	Gentoo Toolchain, Paul Eggert, Frederic Berat

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

Evening,

Adam Sampson <ats@offog.org> writes:
> If the consensus on this does come down to the definition of new
> architecture triplets, are there any other changes that should (or
> could) be made at the same time, beyond time64 and LFS?

Forwarding a suggestion from Arfrever:
> Please consider making regoff_t 64-bit, on both 32-bit and 64-bit
> architectures.
> https://sourceware.org/bugzilla/show_bug.cgi?id=5945
> https://wiki.musl-libc.org/functional-differences-from-glibc.html#Regular-expressions

If an ABI break is inevitable, or a new ABI for the multilib setups,
this seems like a reasonable thing to include in it from my POV.

Have a good one.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-14 20:26     ` Arsen Arsenović
@ 2022-11-14 20:52       ` Florian Weimer
  2022-11-15  7:39         ` Arsen Arsenović
  0 siblings, 1 reply; 75+ messages in thread
From: Florian Weimer @ 2022-11-14 20:52 UTC (permalink / raw)
  To: Arsen Arsenović
  Cc: Adam Sampson, Florian Weimer via Libc-alpha, Sam James, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Paul Eggert, Frederic Berat

* Arsen Arsenović:

> Evening,
>
> Adam Sampson <ats@offog.org> writes:
>> If the consensus on this does come down to the definition of new
>> architecture triplets, are there any other changes that should (or
>> could) be made at the same time, beyond time64 and LFS?
>
> Forwarding a suggestion from Arfrever:
>> Please consider making regoff_t 64-bit, on both 32-bit and 64-bit
>> architectures.
>> https://sourceware.org/bugzilla/show_bug.cgi?id=5945
>> https://wiki.musl-libc.org/functional-differences-from-glibc.html#Regular-expressions
>
> If an ABI break is inevitable, or a new ABI for the multilib setups,
> this seems like a reasonable thing to include in it from my POV.

Uhm, this seems to be something affecting 64-bit targets, not 32-bit
targets, after the POSIX fix went in?  We have a few more such quirks.
(I understood the question to be about cleanup opportunities for 32-bit
architectures.)

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-13  5:11                       ` Zack Weinberg
@ 2022-11-15  5:06                         ` Sam James
  2022-12-25 19:19                         ` Paul Eggert
  1 sibling, 0 replies; 75+ messages in thread
From: Sam James @ 2022-11-15  5:06 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: autoconf-patches, c-std-porting, Paul Eggert, Florian Weimer, wookey

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



> On 13 Nov 2022, at 05:11, Zack Weinberg <zack@owlfolio.org> wrote:
> 
> On Sat, Nov 12, 2022, at 4:33 PM, Zack Weinberg wrote:
>> On Sat, Nov 12, 2022, at 4:31 PM, Paul Eggert wrote:
>>> Because of the concerns raised in this thread it's become clear that
>>> what's in Autoconf now is too drastic, and I've proposed (though not yet
>>> implemented) a change that will cause AC_SYS_LARGEFILE to continue to
>>> not affect time_t unless there's an affirmative request like
>>> "./configure --enable-year2038".
>> 
>> I am tinkering with an implementation of this right now; more in a couple hours.
> 
> "A couple hours" more like eight, ugh.
> 
> I have not pushed this, and have only tested it lightly on a current Linux.  It needs testing on weird old systems, particularly old AIX, HP-UX, MinGW.
> 
> I don't think a 2.72 release tomorrow is realistic anymore.  The soonest after that I will be able to do one is next weekend, but that should give people time to experiment with this.
> 

The approach sounds right from reading NEWS but I haven't looked at the patch itself yet (or tried it anywhere). I hope
to find some time this week but all of the interesting systems I have access to are still Linux, so not that
interesting for the purposes of testing this.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-12 21:31                   ` Paul Eggert
       [not found]                     ` <951fc967-042c-4978-bd78-8bc4c8706b18@app.fastmail.com>
@ 2022-11-15  5:09                     ` Sam James
  1 sibling, 0 replies; 75+ messages in thread
From: Sam James @ 2022-11-15  5:09 UTC (permalink / raw)
  To: Paul Eggert, Carlos O'Donell via Libc-alpha
  Cc: Wookey, Bruno Haible, Zack Weinberg, Florian Weimer,
	Autoconf Development, c-std-porting, Gentoo Toolchain,
	Gnulib bugs, Arnd Bergmann

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



> On 12 Nov 2022, at 21:31, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 2022-11-12 12:23, Wookey wrote:
>> we can't just have everyone who enabled LFS sometime in the
>> last 20 years suddenly being forced into the time_t change (can we?)
> 
> We've done it in the past.
> 
> AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. Originally it affected only off_t; its effect on other types like ino_t came later. Hence people who initially used AC_SYS_LARGEFILE were later "suddenly forced" into an ino_t width change. Similarly for other non-off_t types that AC_SYS_LARGEFILE affects.
> 
> So there's longstanding precedent for AC_SYS_LARGEFILE changing the width of system types that were formerly unaffected. The difference is that time_t is more widely used than ino_t etc., and people are understandably more concerned about time_t changes.
> 

Thanks, that's a helpful bit of history I wasn't aware of there.

> 
> Because of the concerns raised in this thread it's become clear that what's in Autoconf now is too drastic, and I've proposed (though not yet implemented) a change that will cause AC_SYS_LARGEFILE to continue to not affect time_t unless there's an affirmative request like "./configure --enable-year2038". I am waiting for feedback on that from Zack and others, and am hoping for quick turnaround on this because we do need a new Autoconf release.
> 
> 

Sorry, I missed this until now.

That would work well for me too. It's fine for me at least if the same macro just haas additional compatibilities, even if a bit confusing
at first.

As for further changes (as the original post wasn't exclusive to autoconf),
I await comment from other glibc maintainers as I still feel like we're
pretty stuck about how to handle this overall. But your suggestion
(or zw's patch) puts out or dampens the autoconf fire at least.

Thanks for helping come to a compromise. I know this isn't
a simple or easy topic at all.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-14 20:52       ` Florian Weimer
@ 2022-11-15  7:39         ` Arsen Arsenović
  0 siblings, 0 replies; 75+ messages in thread
From: Arsen Arsenović @ 2022-11-15  7:39 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Adam Sampson, Florian Weimer via Libc-alpha, Sam James, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Paul Eggert, Frederic Berat

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

Morning,

Florian Weimer <fweimer@redhat.com> writes:

> Uhm, this seems to be something affecting 64-bit targets, not 32-bit
> targets, after the POSIX fix went in?  We have a few more such quirks.
> (I understood the question to be about cleanup opportunities for 32-bit
> architectures.)

Hmm, yes, not sure what he meant.  The ABI being fine on 32-bit slipped
by me when forwarding.  I'll forward any clarification.

Have a great day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-13  5:11                       ` Zack Weinberg
  2022-11-15  5:06                         ` Sam James
@ 2022-12-25 19:19                         ` Paul Eggert
  2022-12-29  4:02                           ` Zack Weinberg
  1 sibling, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2022-12-25 19:19 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Florian Weimer, sam, wookey, autoconf-patches, c-std-porting

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

On 11/12/22 21:11, Zack Weinberg wrote:
> "A couple hours" more like eight, ugh.

I know the feeling. I didn't get time free until recently.

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.

* 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, and since this year-2038 business only 
occurs with glibc it's not something Autoconf can (or is likely to be 
able to) fix anywhere.

To help things move forward I installed your patch into Autoconf master 
on Savannah, and followed up with the attached patch which tries to 
address the above issues. In particular, it notes that the difference 
between AC_SYS_LARGEFILE and AC_SYS_YEAR2038 is a temporary hack, in 
that eventually (hopefully well before the year 2038) AC_SYS_LARGEFILE 
will be an alias for what AC_SYS_YEAR2038 does now.

Comments welcome of course.

I tested this by migrating these Autoconf changes into my private copy 
of Gnulib and gzip, and building gzip on both 32- and 64-bit glibc. I 
plan to install those changes on Savannah soon, and to follow up with 
similar changes to GNU coreutils etc. This should help to test these 
Autoconf changes before the next Autoconf is released.

[-- Attachment #2: 0001-Omit-just-added-_REQUIRED-macros.patch --]
[-- Type: text/x-patch, Size: 20472 bytes --]

From 3f3354507bb9c2f1d38412cf566ff9443408023e Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 24 Dec 2022 23:24:54 -0800
Subject: [PATCH] Omit just-added *_REQUIRED macros

They are not needed for Gnulib, and users have an easy way to get
their effect, so for now omit them and just document the easy way.
Also, redo documentation to make it clear that AC_YEAR_2038 is
like AC_SYS_LARGEFILE except with a different year-2038 default.
* NEWS, doc/autoconf.texi: Document the above.
* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_REQUIRED):
(AC_SYS_LARGEFILE_REQUIRED): Remove.  Remove some support code.
Perhaps further simplification could be done but I quit while
I was ahead.
---
 NEWS                     |  43 +++------
 doc/autoconf.texi        | 185 +++++++++++++++++----------------------
 lib/autoconf/specific.m4 |  65 +++-----------
 3 files changed, 104 insertions(+), 189 deletions(-)

diff --git a/NEWS b/NEWS
index d9c6ed94..5e8a7606 100644
--- a/NEWS
+++ b/NEWS
@@ -27,37 +27,18 @@ GNU Autoconf NEWS - User visible changes.
 
 ** New features
 
-*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
-  These macros attempt to enlarge time_t to 64 bits, on systems where
-  it has historically been only 32 bits wide, and therefore (assuming
-  the usual Unix epoch) cannot represent dates after mid-January of
-  2038 (hence the names).  The difference between the two is that
-  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
-  out if 64-bit time_t is not available.
-
-  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.
-
-  Library authors should be cautious about adding these macros to
-  their configure scripts; they can break binary backward compatibility.
-
-*** New macro AC_SYS_LARGEFILE_REQUIRED.
-  This macro is the same as the existing AC_SYS_LARGEFILE except that
-  it will cause 'configure' to error out if 64-bit off_t is not available,
-  and it does not provide a --disable-largefile option.
-
-*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
-  As an experimental measure to make it easier to rebuild old programs
-  with support for dates after Jan 2038, if you regenerate any configure
-  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
-  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
-  program is configured with this option, time_t will be enlarged if
-  possible, as if AC_SYS_YEAR2038 had been used.
-
-  Using this option in a library build also potentially breaks binary
-  backward compatibility.
+*** 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.
 
 *** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions
   by defining __STDC_WANT_IEC_60559_EXT__.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index df96280b..42fa24fe 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8798,72 +8798,95 @@ if the system supports @samp{#!}, @samp{no} if not.
 @defmac AC_SYS_LARGEFILE
 @acindex{SYS_LARGEFILE}
 @cvindex _FILE_OFFSET_BITS
+@cvindex _TIME_BITS
 @ovindex CC
 @cindex Large file support
 @cindex LFS
-If the default @code{off_t} type is a 32-bit integer, and therefore
-cannot be used to work with files larger than 4 gigabytes, arrange to
-make a larger @code{off_t} available, if the system supports this.
-Several other types related to the sizes of files and file systems will
-also be enlarged: @code{ino_t}, @code{blkcnt_t}, @code{fsblkcnt_t},
-@code{fsfilcnt_t}, and possibly @code{dev_t}.
-
-If a large @code{off_t} is available (whether or not any arrangements
-were necessary), the shell variable @code{ac_have_largefile} will be set
-to @samp{yes}; if not, it will be set to @samp{no}.
-
-Preprocessor macros will be defined if necessary to make a larger
-@code{off_t} available.  (For example, on many systems the macro
-@code{_FILE_OFFSET_BITS} will be defined.)  Some of these macros only
-work if they are defined before the first system header is included;
-therefore, when using this macro in concert with
-@code{AC_CONFIG_HEADERS}, make sure that @file{config.h} is included
-before any system headers.
-
-On a few older systems, the output variable @code{CC} will also be
-changed to add special compiler options that are needed to enable large
-@code{off_t}.
+If the default @code{off_t} type is a 32-bit integer so
+applications can deal only with files containing less than 2 GiB,
+make a wider @code{off_t} available if the system supports this.
+This may also widen several other types related to files and file
+systems, including @code{blkcnt_t}, @code{dev_t}, @code{ino_t},
+@code{fsblkcnt_t}, and @code{fsfilcnt_t}.
+
+Also, arrange for a @command{configure} option to request widening the
+type @code{time_t} as needed to represent file timestamps and other
+timestamps after January 2038.  If year-2038 support is requested but
+@command{configure} fails to find a way to enable a wide @code{time_t}
+and inspection of the system suggests that this feature is available
+somehow, @command{configure} will error out.
+
+In this version of Autoconf, the year-2038 @command{configure} option
+currently defaults to @code{--disable-year2038}.  If you want the
+default to be @code{--enable-year2038}, you can use
+@code{AC_SYS_YEAR2038} instead of @code{AC_SYS_LARGEFILE}.  In other
+words, packages that use @code{AC_SYS_LARGEFILE} can be made ready for
+the year 2038 either by switching to @code{AC_SYS_YEAR2038}, or by
+configuring with @option{--enable-year2038}.  A future version of
+Autoconf is planned to change the @code{AC_SYS_LARGEFILE} default to
+@code{--enable-year2038}; when that happens, @code{AC_SYS_LARGEFILE} and
+@code{AC_SYS_YEAR2038} will be equivalent.  @xref{AC_SYS_YEAR2038}.
+
+Set the shell variable @code{ac_have_largefile} to to @samp{yes} or
+@code{no} depending on whether a wide @code{off_t} is available,
+regardless of whether arrangements were necessary.  Similarly, set the
+shell variable @code{ac_have_year2038} to @code{yes} or @code{no}
+depending on whether a wide-enough @code{time_t} is available.  If your
+package requires large-file or year-2038 support, you can use code like this:
+
+@example
+AS_IF([test $ac_have_year2038 = no],
+  [AC_MSG_FAILURE([year-2038 support missing])])
+@end example
+
+Define preprocessor macros if necessary to make types wider; For
+example, on many systems the macros @code{_FILE_OFFSET_BITS} and
+@code{_TIME_BITS} can be defined.  Some of these macros work only if
+they are defined before the first system header is included; therefore,
+when using this macro in concert with @code{AC_CONFIG_HEADERS}, make
+sure that @file{config.h} is included before any system headers.
+
+On a few older systems, also change the output variable @code{CC} to add
+special compiler options that are needed to enable large @code{off_t}.
 
 Large-file support can be disabled by configuring with the
-@option{--disable-largefile} option.  Note that this has no effect on
-systems where @code{off_t} is 64 bits or larger by default.  Disabling
-large-file support can have surprising effects, such as causing
-functions like @code{readdir} and @code{stat} to fail on small files
-(because their @emph{inode numbers} are unrepresentable).
+@option{--disable-largefile} option, and year-2038 support can
+be enabled and disabled via the @option{--enable-year2038} and
+@option{--disable-year2038} options.  These options have no effect on
+systems where types are wide enough by default.
+Large-file support is required for year-2038 support: if you configure
+with @option{--disable-largefile} on a platform with 32-bit
+@code{time_t}, then year-2038 support is not available.
+
+Disabling large-file or year-2038 support can have surprising effects,
+such as causing functions like @code{readdir} and @code{stat} to fail
+even on small files because their inode numbers are unrepresentable, or
+causing functions like @code{stat} to fail because a file's timestamp is
+out of range.
 
 Regardless of whether you use this macro, portable programs should not
 assume that any of the types listed above fit into a @code{long int}.
-For example, it is not correct to print an arbitrary @code{off_t} value
-@code{X} with @code{printf ("%ld", (long int) X)}.
-
-Note that the standard C library functions @code{fseek} and @code{ftell}
-do not use @code{off_t}.  If you need to use either of these functions,
-you should use @code{AC_FUNC_FSEEKO} as well as @code{AC_SYS_LARGEFILE},
-and then use their Posix replacements @code{fseeko} and @code{ftello},
-which @emph{do} use @code{off_t}, when available.  @xref{AC_FUNC_FSEEKO}.
-
-As of Autoconf 2.72, @code{AC_SYS_LARGEFILE} also @emph{optionally}
-arranges to enlarge @code{time_t}.  This is to make it easier to build
-programs that support timestamps after 2038; many configure scripts will
-not need to be modified, only regenerated with newer Autoconf.  When
-@code{AC_SYS_LARGEFILE} is used, and @code{AC_SYS_YEAR2038} is
-@emph{not} used, @code{time_t} will normally be left at the system's
-default size, but you can request it be enlarged by configuring with the
-@option{--enable-year2038} option.  (When @code{AC_SYS_YEAR2038} is also
-used, @code{time_t} is enlarged if possible.  @xref{AC_SYS_YEAR2038}.)
-@end defmac
-
-@defmac AC_SYS_LARGEFILE_REQUIRED
-@acindex{SYS_LARGEFILE_REQUIRED}
-This macro has the same effect as @code{AC_SYS_LARGEFILE},
-but also declares that the program being configured
-@emph{requires} support for large files.
-If a large @code{off_t} is unavailable,
-@command{configure} will error out.
-The @option{--disable-largefile} option will not be available.
+For example, it is not portable to print an arbitrary @code{off_t} or
+@code{time_t} value @code{X} with @code{printf ("%ld", (long int) X)}.
+
+The standard C library functions @code{fseek} and @code{ftell} do not
+use @code{off_t}.  If you need to use either of these functions, you
+should use @code{AC_FUNC_FSEEKO} as well as @code{AC_SYS_LARGEFILE}, and
+then use their Posix replacements @code{fseeko} and @code{ftello}.
+@xref{AC_FUNC_FSEEKO}.
+
+When using @code{AC_SYS_LARGEFILE} in different packages that are linked
+together and that have ABIs that depend on the width of @code{off_t},
+@code{time_t} or related types, the simplest thing is to configure all
+components the same way.  For example, if an application uses
+@code{AC_SYS_LARGEFILE} and is configured with
+@option{--enable-year2038}, libraries it links to with an @code{off_t}-
+or @code{time_t}-dependent ABI should be configured equivalently.
+Alternatively, you can modify libraries to support both 32- and 64-bit
+ABIs though this is more work and typically few libraries other than the
+C library itself are modified in this way.
 @end defmac
 
-
 @anchor{AC_SYS_LONG_FILE_NAMES}
 @defmac AC_SYS_LONG_FILE_NAMES
 @acindex{SYS_LONG_FILE_NAMES}
@@ -8885,55 +8908,9 @@ system.  If so, set the shell variable @code{ac_cv_sys_posix_termios} to
 @anchor{AC_SYS_YEAR2038}
 @defmac AC_SYS_YEAR2038
 @acindex{SYS_YEAR2038}
-@cvindex _TIME_BITS
 @cindex Year 2038
-If the default @code{time_t} type is a signed 32-bit integer,
-and therefore (assuming the usual Unix epoch) cannot represent
-timestamps after mid-January of 2038, arrange to make a larger
-@code{time_t} available, if the system supports this.
-
-If a large @code{time_t} is available (whether or not any arrangements
-were necessary), the shell variable @code{ac_have_year2038} will be set
-to @samp{yes}; if not, it will be set to @samp{no}.
-
-Preprocessor macros will be defined if necessary to make a larger
-@code{time_t} available.  (For example, on some systems the macro
-@code{_TIME_BITS} will be defined.)  Some of these macros only work if
-they are defined before the first system header is included; therefore,
-when using this macro in concert with @code{AC_CONFIG_HEADERS}, make
-sure that @file{config.h} is included before any system headers.
-
-Support for timestamps after 2038 can be disabled by configuring with
-the @option{--disable-year2038} option.  Note that this has no effect on
-systems where @code{time_t} is 64 bits or larger by default.
-If this option is @emph{not} given, and @command{configure} fails to
-find a way to enable a large @code{time_t}, but inspection of the
-system suggests that this feature is available @emph{somehow}, it will
-error out.
-
-Regardless of whether you use this macro, portable programs should not
-assume that @code{time_t} fits into @code{long int}.  For example, it is
-not correct to print an arbitrary @code{time_t} value @code{X} with
-@code{printf ("%ld", (long int) X)}.
-
-@strong{Caution:} If you are developing a shared library, and
-@code{time_t} appears anywhere in your library's public interface, use
-of this macro may break binary compatibility with older executables.
-@end defmac
-
-@defmac AC_SYS_YEAR2038_REQUIRED
-@acindex{SYS_YEAR2038_REQUIRED}
-This macro has the same effect as @code{AC_SYS_YEAR2038},
-but also declares that the program being configured
-@emph{requires} support for timestamps after mid-January of 2038.
-If a large @code{time_t} is unavailable,
-@command{configure} will @emph{unconditionally} error out
-(unlike the behavior of @code{AC_SYS_YEAR2038}).
-The @option{--disable-year2038} option will not be available.
-
-@strong{Caution:} If you are developing a shared library, and
-@code{time_t} appears anywhere in your library's public interface, use
-of this macro may break binary compatibility with older executables.
+This is like @code{AC_SYS_LARGEFILE} except it defaults to enabling
+instead of disabling year-2038 support.  @xref{AC_SYS_LARGEFILE}.
 @end defmac
 
 @node C and Posix Variants
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 0493d01d..6f9b89bc 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -156,8 +156,6 @@ AS_CASE([$ac_cv_sys_year2038_opts],
   ["support not detected"],
     [ac_have_year2038=no
      AS_CASE([$enable_year2038],
-      [required],
-        [AC_MSG_FAILURE([support for timestamps after Jan 2038 is required])],
       [yes],
         [# If we're not cross compiling and 'touch' works with a large
         # timestamp, then we can presume the system supports wider time_t
@@ -204,22 +202,19 @@ AS_CASE([$ac_cv_sys_year2038_opts],
 # --enable-year2038, or a --disable-year2038, or no option at all to
 # the configure script.  Note that 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
+# default value for enable_year2038 is emitted unconditionally
 # because the generated code always looks at this variable.
 m4_define([_AC_SYS_YEAR2038_ENABLE],
 [m4_divert_text([DEFAULTS],
-  m4_provide_if([AC_SYS_YEAR2038_REQUIRED],
-    [enable_year2038=required],
   m4_provide_if([AC_SYS_YEAR2038],
     [enable_year2038=yes],
-    [enable_year2038=no])))]dnl
-[m4_provide_if([AC_SYS_YEAR2038_REQUIRED], [],
+    [enable_year2038=no]))]dnl
 [AC_ARG_ENABLE([year2038],
   m4_provide_if([AC_SYS_YEAR2038],
     [AS_HELP_STRING([--disable-year2038],
-      [omit support for dates after Jan 2038])],
+      [do not support timestamps after 2038])],
     [AS_HELP_STRING([--enable-year2038],
-      [include support for dates after Jan 2038])]))])])
+      [support timestamps after 2038])]))])
 
 # _AC_SYS_YEAR2038_OPT_IN
 # -----------------------
@@ -241,28 +236,12 @@ AC_DEFUN([_AC_SYS_YEAR2038_OPT_IN],
 # On systems where time_t is not always 64 bits, this probe can be
 # skipped by passing the --disable-year2038 option to configure.
 AC_DEFUN([AC_SYS_YEAR2038],
-[m4_provide_if([AC_SYS_LARGEFILE_REQUIRED], [],
-  [AC_REQUIRE([AC_SYS_LARGEFILE])])]dnl
+[AC_REQUIRE([AC_SYS_LARGEFILE])]dnl
 [m4_provide_if([_AC_SYS_YEAR2038_PROBE], [], [dnl
   AS_IF([test "$enable_year2038" != no], [_AC_SYS_YEAR2038_PROBE])
   AC_CONFIG_COMMANDS_PRE([_AC_SYS_YEAR2038_ENABLE])
 ])])
 
-# AC_SYS_YEAR2038_REQUIRED
-# ------------------------
-# Same as AC_SYS_YEAR2038, but declares that this program *requires*
-# support for large time_t.  If we cannot find any way to make time_t
-# capable of representing values larger than 2**31 - 1, configure will
-# error out.  Furthermore, no --enable-year2038 nor --disable-year2038
-# option will be available.
-AC_DEFUN([AC_SYS_YEAR2038_REQUIRED],
-[m4_provide_if([AC_SYS_LARGEFILE_REQUIRED], [],
-  [AC_REQUIRE([AC_SYS_LARGEFILE])])]dnl
-[m4_provide_if([_AC_SYS_YEAR2038_PROBE], [], [dnl
-  _AC_SYS_YEAR2038_PROBE
-  AC_CONFIG_COMMANDS_PRE([_AC_SYS_YEAR2038_ENABLE])
-])])
-
 # _AC_SYS_LARGEFILE_TEST_CODE
 # ---------------------------
 # C code used to probe for large file support.
@@ -323,9 +302,7 @@ ac_have_largefile=yes
 AS_CASE([$ac_cv_sys_largefile_opts],
   ["none needed"], [],
   ["support not detected"],
-    [ac_have_largefile=no
-     AS_IF([test $enable_largefile = required],
-       [AC_MSG_FAILURE([support for large files is required])])],
+    [ac_have_largefile=no],
 
   ["-D_FILE_OFFSET_BITS=64"],
     [AC_DEFINE([_FILE_OFFSET_BITS], [64],
@@ -346,21 +323,16 @@ _AC_SYS_YEAR2038_OPT_IN
 
 # _AC_SYS_LARGEFILE_ENABLE
 # ------------------------
-# Subroutine of AC_SYS_LARGEFILE.  If AC_SYS_LARGEFILE_REQUIRED was
-# not used at any point in this configure script, add a
-# --disable-largefile option to the configure script.  Note that this
+# Subroutine of AC_SYS_LARGEFILE.  Note that this
 # is expanded very late and therefore there cannot be any code in the
-# AC_ARG_ENABLE.  The default value for `enable_largefile` is emitted
+# AC_ARG_ENABLE.  The default value for enable_largefile is emitted
 # unconditionally because the generated shell code always looks at
 # this variable.
 m4_define([_AC_SYS_LARGEFILE_ENABLE],
 [m4_divert_text([DEFAULTS],
-  m4_provide_if([AC_SYS_LARGEFILE_REQUIRED],
-    [enable_largefile=required],
-    [enable_largefile=yes]))]dnl
-[m4_provide_if([AC_SYS_LARGEFILE_REQUIRED], [],
+  enable_largefile=yes)]dnl
 [AC_ARG_ENABLE([largefile],
-  [AS_HELP_STRING([--disable-largefile], [omit support for large files])])])])
+  [AS_HELP_STRING([--disable-largefile], [omit support for large files])])])
 
 # AC_SYS_LARGEFILE
 # ----------------
@@ -372,28 +344,13 @@ m4_define([_AC_SYS_LARGEFILE_ENABLE],
 # to have a 64-bit inode number cannot be accessed by 32-bit applications on
 # Linux x86/x86_64.  This can occur with file systems such as XFS and NFS.
 # This macro allows configuration to continue if the system doesn't support
-# large files; see also AC_SYS_LARGEFILE_REQUIRED.
+# large files.
 AC_DEFUN([AC_SYS_LARGEFILE],
 [m4_provide_if([_AC_SYS_LARGEFILE_PROBE], [], [dnl
   AS_IF([test "$enable_largefile" != no], [_AC_SYS_LARGEFILE_PROBE])
   AC_CONFIG_COMMANDS_PRE([_AC_SYS_LARGEFILE_ENABLE])
 ])])
 
-# AC_SYS_LARGEFILE_REQUIRED
-# -------------------------
-# Same as AC_SYS_LARGEFILE, but declares that this program *requires*
-# support for large files.  If we cannot find a combination of compiler
-# options and #defines that makes `off_t` capable of representing 2**63 - 1,
-# `configure` will error out.  Furthermore, `configure` will not offer a
-# --disable-largefile command line option.
-# If both AC_SYS_LARGEFILE and AC_SYS_LARGEFILE_REQUIRED are used in the
-# same configure script -- in either order -- AC_SYS_LARGEFILE_REQUIRED wins.
-AC_DEFUN([AC_SYS_LARGEFILE_REQUIRED],
-[m4_provide_if([_AC_SYS_LARGEFILE_PROBE], [], [dnl
-  _AC_SYS_LARGEFILE_PROBE
-  AC_CONFIG_COMMANDS_PRE([_AC_SYS_LARGEFILE_ENABLE])
-])])
-
 # AC_SYS_LONG_FILE_NAMES
 # ----------------------
 # Security: use a temporary directory as the most portable way of
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-12-25 19:19                         ` Paul Eggert
@ 2022-12-29  4:02                           ` Zack Weinberg
  2022-12-30 22:12                             ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Zack Weinberg @ 2022-12-29  4:02 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Florian Weimer, sam, wookey, autoconf-patches, c-std-porting

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

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-12-29  4:02                           ` Zack Weinberg
@ 2022-12-30 22:12                             ` Paul Eggert
  2022-12-30 22:20                               ` Sam James
  2023-01-20  9:56                               ` Paul Eggert
  0 siblings, 2 replies; 75+ messages in thread
From: Paul Eggert @ 2022-12-30 22:12 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Florian Weimer, sam, wookey, autoconf-patches, c-std-porting

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

On 12/28/22 20:02, Zack Weinberg wrote:

> Please revert that part of your follow-up patch.
OK, I reverted all that patch, except for the further changes you 
requested, plus some minor quoting and version-number fixes in comments.

> 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?

Sure, I'm attaching a proposed patch to Autoconf master documentation in 
two forms. The first is a simple "git format-patch" file; the second is 
the output of "git diff --color=always --word-diff=color".

> 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.

Although I don't think this feature is useful, I don't have to use it so 
we can leave it in.

Here's why I'm not planning to use it. I help maintain (for example) GNU 
Tar, where file sizes and timestamps are crucial. But if I change GNU 
Tar to use AC_SYS_LARGEFILE_REQUIRED, people won't be able to build GNU 
Tar on ancient platforms that support file sizes only up to 2 GiB. 
Nobody will benefit from this: the very few users who'd care (computer 
museum curators, say) already know their systems are limited, and will 
simply build older versions of GNU Tar that don't use 
AC_SYS_LARGEFILE_REQUIRED, or will edit away the "_REQUIRED" before 
building. So adding the _REQUIRED will harm a very small set of users, 
will increase my maintenance burden a bit, and will benefit essentially 
nobody.

To put it another way: we've all gotten by without needing 
AC_SYS_LARGEFILE_REQUIRED for 25 years, and there's no reason for us to 
start needing it now even though it's imperative for any serious 
application that deals with files.

The situation for AC_SYS_YEAR2038_REQUIRED will likely be similar.

As things currently stand, I plan to use AC_SYS_YEAR2038 instead of 
AC_SYS_LARGEFILE in GNU Tar and similar applications. (They'll use 
Gnulib so they'll get Autoconf 2.72-compatible AC_SYS_YEAR2038 even with 
older Autoconf.) Perhaps other maintainers will want to use the 
*_REQUIRED macros, but as far as I can see my advice will be to avoid 
them as being more trouble than they're worth.


> 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

Unfortunately the documenation currently on Autoconf master makes for a 
lot of confusion and misimpression. It's more important for 
documentation to agree with what the code actually does, than for it to 
present an abstract picture of what we'd like the code to do eventually. 
The abovementioned patches fix this.


> In the new year, I can look into the possibility of decoupling the
> macros’ implementations.

I don't see how that would be possible. On the only platforms where 
--enable-year2038 matters, you cannot have year-2038 support without 
also having large-file support.

The platforms in question are glibc 2.34+ on 32-bit ARM and x86. The 
glibc community considered making the two things orthogonal but rejected 
that alternative as being considerably more trouble than it was worth. I 
think it unlikely for other 32-bit OS suppliers to decide differently.


> I think you’re still writing documentation with application-colored
> glasses on, making it sound like --enable-year2038 has no negative
> implications whatsoever.

That's a bit unfair. The proposed documentation does mention the 
compatibility implications; it merely uses the same level of caution for 
both --enable-largefile and --enable-year2038, and it doesn't overhype 
the time_t issue with an undeserved big "Caution:" inbold.

Although I plead guilty in being close to users (many who need year 2038 
support now for obvious reasons) I'm well aware of the implication for 
libraries. When I implemented AC_SYS_LARGEFILE back in the 1990s, there 
were similar compatibility concerns with off_t that I also took 
seriously. In the end, the need for large-file support outweighed the 
backward-compatibility hassles and AC_SYS_LARGEFILE has been a success 
in that people have used AC_SYS_LARGEFILE for years and sure there are 
occasionally glitches but the benefits far outweigh the costs.

AC_SYS_YEAR2038 will be similar. Not identical of course, but similar. 
We've done this sort of thing before and have experience.


> 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.”

The proposed documentation patches contain a simple plan for how 
Autoconf can plausibly survive through the year 2038. Is there a better 
plan? If so, I'd like to hear it. If not, then let's use this plan. 
Given the long delay between Autoconf versions and end uses of 
downstream software, we need a plan now, not years from now. The plan 
doesn't have to be perfect, nor does it need to be cast in stone. But 
there needs to be a plan.

[-- Attachment #2: 0001-Improve-year-2038-documentation.patch --]
[-- Type: text/x-patch, Size: 16832 bytes --]

From 3e9f1159ae9145c50d048a74422dd8464a6a8f6f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 30 Dec 2022 12:48:39 -0800
Subject: [PATCH] Improve year-2038 documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* NEWS, doc/autoconf.texi (System Services):
Improve documentation for behavior of largefile and year-2038 support.
Say that in the current implementation, year-2038 support
requires largefile support.  Say that year-2038 support
matters only for GNU/Linux glibc 2.34+ on 32-bit x86 and ARM.
Prefer brevity when this does not hurt understandability;
for example, prefer active to passive voice.
Prefer “wider” to “larger” when talking about the number of
bits in an integer, as this terminology is more standard.
Tone down the wording in warnings about enabling year-2038 support,
use similar wording in warnings about enabling largefile support,
and warn also about disabling largefile and year-2038 support.
No need for @emph.  Also mention rlim_t.
Be a bit more careful about saying “2 GiB” rather than “2 GB”.
Mention that a future version of Autoconf might change
AC_SYS_LARGEFILE to default to --enable-year2038, since
something has gotta happen before 2038.
Coalesce descriptions of --enable-largefile and --enable-year2038
to simplify documentation.  Mention that the only system where
AC_SYS_LARGEFILE changes CC is IRIX and that these systems
are obsolete.  Say that ‘stat’ can fail due to time_t
overflow.  Say that you can’t portably print time_t with %ld.
Say that binary compatibilty problems also can occur when one
library is linking to amother; it’s not just apps vs libraries.
Mention the possibility of modifying libraries to support both
32- and 64-bit interfaces.  Warn more consistently about
ABI compatibility issues, but put the bulk of this text
in one location that the other locations refer to.
---
 NEWS              |  57 ++++++++--------
 doc/autoconf.texi | 165 ++++++++++++++++++++++++----------------------
 2 files changed, 113 insertions(+), 109 deletions(-)

diff --git a/NEWS b/NEWS
index eafd7d69..0f71628d 100644
--- a/NEWS
+++ b/NEWS
@@ -27,36 +27,33 @@ GNU Autoconf NEWS - User visible changes.
 
 ** New features
 
-*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
-  These macros attempt to enlarge time_t to 64 bits, on systems where
-  it has historically been only 32 bits wide, and therefore (assuming
-  the usual Unix epoch) cannot represent dates after mid-January of
-  2038 (hence the names).  The difference between the two is that
-  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
-  out if 64-bit time_t is not available.
-
-  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.
-
-  Library authors should be cautious about adding these macros to
-  their configure scripts; they can break binary backward compatibility.
-
-*** New macro AC_SYS_LARGEFILE_REQUIRED.
-  This macro is the same as the existing AC_SYS_LARGEFILE except that
-  it will cause 'configure' to error out if 64-bit off_t is not available,
-  and it does not provide a --disable-largefile option.
-
-*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
-  As an experimental measure to make it easier to rebuild old programs
-  with support for dates after Jan 2038, if you regenerate any configure
-  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
-  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
-  program is configured with this option, time_t will be enlarged if
-  possible, as if AC_SYS_YEAR2038 had been used.
-
-  Using this option in a library build also potentially breaks binary
-  backward compatibility.
+*** New macro AC_SYS_YEAR2038.
+  This causes 'configure' to widen time_t if possible on systems where
+  time_t by default cannot represent file and other timestamps after
+  January 2038.  Widening is possible only on 32-bit GNU/Linux x86 and
+  ARM systems with glibc 2.34 or later.  To prevent widening,
+  configure with --disable-year2038.
+
+  This macro also has the effects as AC_SYS_LARGEFILE, because in
+  practice time_t cannot be widened without large-file sypport.
+
+  Application and library builders should take care that packages
+  configured with --enable-year2038 and --disable-year2038 options
+  are configured consistently, to avoid breaking binary compatibility.
+  This is similar to longstanding consistency requirements with
+  --enable-largefile and --disable-largefile.
+
+*** AC_SYS_LARGEFILE now optionally arranges to widen time_t.
+  It now acts like AC_SYS_YEAR2038, except 'configure' defaults to
+  --disable-year2038 unless AC_SYS_YEAR2038 is also present.
+  As with AC_SYS_YEAR2038, application and library builders should
+  configure consistently.
+
+*** New macros AC_SYS_LARGEFILE_REQUIRED and AC_SYS_YEAR2038_REQUIRED.
+  These act like AC_SYS_LARGEFILE and AC_SYS_YEAR2038 respectively,
+  except that they require large-file and year-2038 support respectively.
+  As with AC_SYS_YEAR2038, application and library builders should
+  configure consistently.
 
 *** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions
   by defining __STDC_WANT_IEC_60559_EXT__.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index df96280b..ce214284 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8798,71 +8798,109 @@ if the system supports @samp{#!}, @samp{no} if not.
 @defmac AC_SYS_LARGEFILE
 @acindex{SYS_LARGEFILE}
 @cvindex _FILE_OFFSET_BITS
+@cvindex _TIME_BITS
 @ovindex CC
 @cindex Large file support
 @cindex LFS
-If the default @code{off_t} type is a 32-bit integer, and therefore
-cannot be used to work with files larger than 4 gigabytes, arrange to
-make a larger @code{off_t} available, if the system supports this.
-Several other types related to the sizes of files and file systems will
-also be enlarged: @code{ino_t}, @code{blkcnt_t}, @code{fsblkcnt_t},
-@code{fsfilcnt_t}, and possibly @code{dev_t}.
-
-If a large @code{off_t} is available (whether or not any arrangements
-were necessary), the shell variable @code{ac_have_largefile} will be set
-to @samp{yes}; if not, it will be set to @samp{no}.
-
-Preprocessor macros will be defined if necessary to make a larger
-@code{off_t} available.  (For example, on many systems the macro
-@code{_FILE_OFFSET_BITS} will be defined.)  Some of these macros only
-work if they are defined before the first system header is included;
+If the default @code{off_t} type is a 32-bit integer,
+and therefore cannot be used with files 2 GiB or larger,
+make a wider @code{off_t} available if the system supports it.
+Similarly, widen other types related to sizes of files and file systems
+if possible.  These types may include @code{blkcnt_t}, @code{dev_t},
+@code{ino_t}, @code{fsblkcnt_t}, @code{fsfilcnt_t}, and @code{rlim_t}.
+
+Also, arrange for a @command{configure} option @code{--enable-year2038}
+to request widening the type @code{time_t} as needed to represent file
+wand other timestamps after January 2038.  This widening is possible
+only on 32-bit GNU/Linux x86 and ARM systems with glibc 2.34 or later.
+If year-2038 support is requested but @command{configure} fails to find a way
+to widen @code{time_t} and inspection of the system suggests that
+this feature is available somehow, @command{configure} will error out.
+If you want the default to be @code{--enable-year2038}, you can use
+@code{AC_SYS_YEAR2038} instead of @code{AC_SYS_LARGEFILE}.
+In other words, older packages that have long used @code{AC_SYS_LARGEFILE}
+can have year-2038 support on 32-bit GNU/Linux x86 and ARM systems either by
+regenerating @file{configure} with current Autoconf and configuring with
+@option{--enable-year2038}, or by using @code{AC_SYS_YEAR2038} and
+configuring without @option{--disable-year2038}.
+A future version of Autoconf might change the @code{AC_SYS_LARGEFILE}
+default to @code{--enable-year2038}; if and when that happens,
+@code{AC_SYS_LARGEFILE} and @code{AC_SYS_YEAR2038} will become equivalent.
+@xref{AC_SYS_YEAR2038}.
+
+Set the shell variable @code{ac_have_largefile} to to @samp{yes} or
+@code{no} depending on whether a wide @code{off_t} is available,
+regardless of whether arrangements were necessary.
+Similarly, set the shell variable @code{ac_have_year2038} to @code{yes}
+or @code{no} depending on whether a wide-enough @code{time_t} is available.
+
+Define preprocessor macros if necessary to make types wider;
+for example, on GNU/Linux systems the macros @code{_FILE_OFFSET_BITS}
+and @code{_TIME_BITS} can be defined.  Some of these macros work only if
+defined before the first system header is included;
 therefore, when using this macro in concert with
 @code{AC_CONFIG_HEADERS}, make sure that @file{config.h} is included
 before any system headers.
 
-On a few older systems, the output variable @code{CC} will also be
-changed to add special compiler options that are needed to enable large
-@code{off_t}.
+On obsolete IRIX systems, also change the output variable @code{CC} to
+add compiler options needed for wide @code{off_t}.
 
 Large-file support can be disabled by configuring with the
-@option{--disable-largefile} option.  Note that this has no effect on
-systems where @code{off_t} is 64 bits or larger by default.  Disabling
-large-file support can have surprising effects, such as causing
-functions like @code{readdir} and @code{stat} to fail on small files
-(because their @emph{inode numbers} are unrepresentable).
+@option{--disable-largefile} option, and year-2038 support can
+be enabled and disabled via the @option{--enable-year2038} and
+@option{--disable-year2038} options.  These options have no effect on
+systems where types are wide enough by default.
+Large-file support is required for year-2038 support: if you configure
+with @option{--disable-largefile} on a platform with 32-bit
+@code{time_t}, then year-2038 support is not available.
+
+Disabling large-file or year-2038 support can have surprising effects,
+such as causing functions like @code{readdir} and @code{stat} to fail
+even on a small file because its inode number or timestamp is out of range.
 
 Regardless of whether you use this macro, portable programs should not
 assume that any of the types listed above fit into a @code{long int}.
-For example, it is not correct to print an arbitrary @code{off_t} value
-@code{X} with @code{printf ("%ld", (long int) X)}.
+For example, it is not portable to print an arbitrary @code{off_t} or
+@code{time_t} value @code{X} with @code{printf ("%ld", (long int) X)}.
 
-Note that the standard C library functions @code{fseek} and @code{ftell}
+The standard C library functions @code{fseek} and @code{ftell}
 do not use @code{off_t}.  If you need to use either of these functions,
 you should use @code{AC_FUNC_FSEEKO} as well as @code{AC_SYS_LARGEFILE},
-and then use their Posix replacements @code{fseeko} and @code{ftello},
-which @emph{do} use @code{off_t}, when available.  @xref{AC_FUNC_FSEEKO}.
-
-As of Autoconf 2.72, @code{AC_SYS_LARGEFILE} also @emph{optionally}
-arranges to enlarge @code{time_t}.  This is to make it easier to build
-programs that support timestamps after 2038; many configure scripts will
-not need to be modified, only regenerated with newer Autoconf.  When
-@code{AC_SYS_LARGEFILE} is used, and @code{AC_SYS_YEAR2038} is
-@emph{not} used, @code{time_t} will normally be left at the system's
-default size, but you can request it be enlarged by configuring with the
-@option{--enable-year2038} option.  (When @code{AC_SYS_YEAR2038} is also
-used, @code{time_t} is enlarged if possible.  @xref{AC_SYS_YEAR2038}.)
+and then use their Posix replacements @code{fseeko} and @code{ftello}.
+@xref{AC_FUNC_FSEEKO}.
+
+When using @code{AC_SYS_LARGEFILE} in different packages that are linked
+together and that have interfaces that depend on the width of @code{off_t},
+@code{time_t} or related types, the simplest thing is to configure all
+components the same way.  For example, if an application uses
+@code{AC_SYS_LARGEFILE} and is configured with
+@option{--enable-year2038}, libraries it links to with an @code{off_t}-
+or @code{time_t}-dependent interface should be configured equivalently.
+Alternatively, you can modify libraries to support both 32- and 64-bit
+interfaces though this is more work and few libraries other than the C
+library itself are modified in this way.
+
+Applications and libraries should be configured compatibly.
+If @code{off_t}, @code{time_t} or related types appear in a library's
+public interface, enabling or disabling the library's large-file or
+year-2038 support may break binary compatibility with applications or
+with other libraries.  Similarly, if an application links to a such a
+library, enabling or disabling the application's large-file support may
+break binary compatibility with that library.
 @end defmac
 
 @defmac AC_SYS_LARGEFILE_REQUIRED
 @acindex{SYS_LARGEFILE_REQUIRED}
 This macro has the same effect as @code{AC_SYS_LARGEFILE},
 but also declares that the program being configured
-@emph{requires} support for large files.
+requires support for large files.
 If a large @code{off_t} is unavailable,
 @command{configure} will error out.
 The @option{--disable-largefile} option will not be available.
-@end defmac
 
+Large-file and year-2038 support for applications and libraries should
+be configured compatibly.  @xref{AC_SYS_LARGEFILE}.
+@end defmac
 
 @anchor{AC_SYS_LONG_FILE_NAMES}
 @defmac AC_SYS_LONG_FILE_NAMES
@@ -8885,55 +8923,24 @@ system.  If so, set the shell variable @code{ac_cv_sys_posix_termios} to
 @anchor{AC_SYS_YEAR2038}
 @defmac AC_SYS_YEAR2038
 @acindex{SYS_YEAR2038}
-@cvindex _TIME_BITS
 @cindex Year 2038
-If the default @code{time_t} type is a signed 32-bit integer,
-and therefore (assuming the usual Unix epoch) cannot represent
-timestamps after mid-January of 2038, arrange to make a larger
-@code{time_t} available, if the system supports this.
-
-If a large @code{time_t} is available (whether or not any arrangements
-were necessary), the shell variable @code{ac_have_year2038} will be set
-to @samp{yes}; if not, it will be set to @samp{no}.
-
-Preprocessor macros will be defined if necessary to make a larger
-@code{time_t} available.  (For example, on some systems the macro
-@code{_TIME_BITS} will be defined.)  Some of these macros only work if
-they are defined before the first system header is included; therefore,
-when using this macro in concert with @code{AC_CONFIG_HEADERS}, make
-sure that @file{config.h} is included before any system headers.
-
-Support for timestamps after 2038 can be disabled by configuring with
-the @option{--disable-year2038} option.  Note that this has no effect on
-systems where @code{time_t} is 64 bits or larger by default.
-If this option is @emph{not} given, and @command{configure} fails to
-find a way to enable a large @code{time_t}, but inspection of the
-system suggests that this feature is available @emph{somehow}, it will
-error out.
-
-Regardless of whether you use this macro, portable programs should not
-assume that @code{time_t} fits into @code{long int}.  For example, it is
-not correct to print an arbitrary @code{time_t} value @code{X} with
-@code{printf ("%ld", (long int) X)}.
-
-@strong{Caution:} If you are developing a shared library, and
-@code{time_t} appears anywhere in your library's public interface, use
-of this macro may break binary compatibility with older executables.
+This is like @code{AC_SYS_LARGEFILE} except it defaults to enabling
+instead of disabling year-2038 support.  Year-2038 support for
+applications and libraries should be configured compatibly.
+@xref{AC_SYS_LARGEFILE}.
 @end defmac
 
 @defmac AC_SYS_YEAR2038_REQUIRED
 @acindex{SYS_YEAR2038_REQUIRED}
 This macro has the same effect as @code{AC_SYS_YEAR2038},
 but also declares that the program being configured
-@emph{requires} support for timestamps after mid-January of 2038.
+requires support for timestamps after mid-January of 2038.
 If a large @code{time_t} is unavailable,
-@command{configure} will @emph{unconditionally} error out
-(unlike the behavior of @code{AC_SYS_YEAR2038}).
+@command{configure} will unconditionally error out.
 The @option{--disable-year2038} option will not be available.
 
-@strong{Caution:} If you are developing a shared library, and
-@code{time_t} appears anywhere in your library's public interface, use
-of this macro may break binary compatibility with older executables.
+Year-2038 support for applications and libraries should be configured
+compatibly.  @xref{AC_SYS_YEAR2038}.
 @end defmac
 
 @node C and Posix Variants
-- 
2.38.1


[-- Attachment #3: Improve-year-2038-doc-wdiff-color.txt --]
[-- Type: text/plain, Size: 15379 bytes --]

^[[1mdiff --git a/NEWS b/NEWS^[[m
^[[1mindex eafd7d69..0f71628d 100644^[[m
^[[1m--- a/NEWS^[[m
^[[1m+++ b/NEWS^[[m
^[[36m@@ -27,36 +27,33 @@^[[m ^[[mGNU Autoconf NEWS - User visible changes.^[[m

** New features^[[m

*** New ^[[31mmacros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.^[[m
^[[31m  These macros attempt^[[m^[[32mmacro AC_SYS_YEAR2038.^[[m
^[[32m  This causes 'configure'^[[m to ^[[31menlarge^[[m^[[32mwiden^[[m time_t ^[[31mto 64 bits,^[[m^[[32mif possible^[[m on systems where
  ^[[31mit has historically been only 32 bits wide, and therefore (assuming^[[m
^[[31m  the usual Unix epoch)^[[m^[[32mtime_t by default^[[m cannot represent ^[[31mdates^[[m^[[32mfile and other timestamps^[[m after
  ^[[31mmid-January of^[[m
^[[31m  2038 (hence the names).  The difference between the two^[[m^[[32mJanuary 2038.  Widening^[[m is ^[[31mthat^[[m
^[[31m  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error^[[m
^[[31m  out if 64-bit time_t is not available.^[[m

^[[31m  Enlarging time_t to 64 bits is likely to have the side effect of^[[m
^[[31m  enlarging off_t^[[m^[[32mpossible only on 32-bit GNU/Linux x86^[[m and
  ^[[31mrelated types to 64 bits as well, as if you^[[m
^[[31m  had used AC_SYS_LARGEFILE.  See the manual for details.^[[m

^[[31m  Library authors should be cautious about adding these macros to^[[m
^[[31m  their^[[m^[[32mARM systems with glibc 2.34 or later.  To prevent widening,^[[m
  configure ^[[31mscripts; they can break binary backward compatibility.^[[m

^[[31m*** New macro AC_SYS_LARGEFILE_REQUIRED.^[[m^[[32mwith --disable-year2038.^[[m

  This macro ^[[31mis^[[m^[[32malso has^[[m the ^[[31msame^[[m^[[32meffects^[[m as ^[[31mthe existing AC_SYS_LARGEFILE except^[[m^[[32mAC_SYS_LARGEFILE, because in^[[m
^[[32m  practice time_t cannot be widened without large-file sypport.^[[m

^[[32m  Application and library builders should take care^[[m that ^[[31mit will cause 'configure'^[[m^[[32mpackages^[[m
^[[32m  configured with --enable-year2038 and --disable-year2038 options^[[m
^[[32m  are configured consistently,^[[m to ^[[31merror out if 64-bit off_t^[[m^[[32mavoid breaking binary compatibility.^[[m
^[[32m  This^[[m is ^[[31mnot available,^[[m^[[32msimilar to longstanding consistency requirements with^[[m
^[[32m  --enable-largefile^[[m and ^[[31mit does not provide a --disable-largefile option.^[[m^[[32m--disable-largefile.^[[m

*** AC_SYS_LARGEFILE now optionally arranges to ^[[31menlarge^[[m^[[32mwiden^[[m time_t.
  ^[[31mAs an experimental measure to make it easier^[[m^[[32mIt now acts like AC_SYS_YEAR2038, except 'configure' defaults^[[m to
  ^[[31mrebuild old programs^[[m^[[32m--disable-year2038 unless AC_SYS_YEAR2038 is also present.^[[m
^[[32m  As^[[m with ^[[31msupport for dates after Jan 2038, if you regenerate any^[[m^[[32mAC_SYS_YEAR2038, application and library builders should^[[m
  configure ^[[31mscript that uses^[[m^[[32mconsistently.^[[m

^[[32m*** New macros AC_SYS_LARGEFILE_REQUIRED and AC_SYS_YEAR2038_REQUIRED.^[[m
^[[32m  These act like^[[m AC_SYS_LARGEFILE ^[[31m(but not AC_SYS_YEAR2038) using^[[m
^[[31m  Autoconf 2.72, it will gain an --enable-year2038 option.  When the^[[m
^[[31m  program is configured with this option, time_t will be enlarged if^[[m
^[[31m  possible, as if^[[m^[[32mand^[[m AC_SYS_YEAR2038 ^[[31mhad been used.^[[m

^[[31m  Using this option in a^[[m^[[32mrespectively,^[[m
^[[32m  except that they require large-file and year-2038 support respectively.^[[m
^[[32m  As with AC_SYS_YEAR2038, application and^[[m library ^[[31mbuild also potentially breaks binary^[[m
^[[31m  backward compatibility.^[[m^[[32mbuilders should^[[m
^[[32m  configure consistently.^[[m

*** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions^[[m
  by defining __STDC_WANT_IEC_60559_EXT__.^[[m
^[[1mdiff --git a/doc/autoconf.texi b/doc/autoconf.texi^[[m
^[[1mindex df96280b..ce214284 100644^[[m
^[[1m--- a/doc/autoconf.texi^[[m
^[[1m+++ b/doc/autoconf.texi^[[m
^[[36m@@ -8798,71 +8798,109 @@^[[m ^[[mif the system supports @samp{#!}, @samp{no} if not.^[[m
@defmac AC_SYS_LARGEFILE^[[m
@acindex{SYS_LARGEFILE}^[[m
@cvindex _FILE_OFFSET_BITS^[[m
^[[32m@cvindex _TIME_BITS^[[m
@ovindex CC^[[m
@cindex Large file support^[[m
@cindex LFS^[[m
If the default @code{off_t} type is a 32-bit integer,
and therefore cannot be used^[[31mto work^[[m with files ^[[31mlarger than 4 gigabytes, arrange to^[[m^[[32m2 GiB or larger,^[[m
make a ^[[31mlarger^[[m^[[32mwider^[[m @code{off_t} ^[[31mavailable,^[[m^[[32mavailable^[[m if the system supports ^[[31mthis.^[[m
^[[31mSeveral^[[m^[[32mit.^[[m
^[[32mSimilarly, widen^[[m other types related to^[[31mthe^[[m sizes of files and file systems
^[[31mwill^[[m
^[[31malso be enlarged: @code{ino_t},^[[m^[[32mif possible.  These types may include^[[m @code{blkcnt_t}, ^[[32m@code{dev_t},^[[m
^[[32m@code{ino_t},^[[m @code{fsblkcnt_t}, @code{fsfilcnt_t}, and ^[[31mpossibly @code{dev_t}.^[[m^[[32m@code{rlim_t}.^[[m

^[[32mAlso, arrange for a @command{configure} option @code{--enable-year2038}^[[m
^[[32mto request widening the type @code{time_t} as needed to represent file^[[m
^[[32mwand other timestamps after January 2038.  This widening is possible^[[m
^[[32monly on 32-bit GNU/Linux x86 and ARM systems with glibc 2.34 or later.^[[m
If ^[[32myear-2038 support is requested but @command{configure} fails to find^[[m a ^[[31mlarge @code{off_t}^[[m^[[32mway^[[m
^[[32mto widen @code{time_t} and inspection of the system suggests that^[[m
^[[32mthis feature^[[m is available ^[[31m(whether^[[m^[[32msomehow, @command{configure} will error out.^[[m
^[[32mIf you want the default to be @code{--enable-year2038}, you can use^[[m
^[[32m@code{AC_SYS_YEAR2038} instead of @code{AC_SYS_LARGEFILE}.^[[m
^[[32mIn other words, older packages that have long used @code{AC_SYS_LARGEFILE}^[[m
^[[32mcan have year-2038 support on 32-bit GNU/Linux x86 and ARM systems either by^[[m
^[[32mregenerating @file{configure} with current Autoconf and configuring with^[[m
^[[32m@option{--enable-year2038},^[[m or ^[[31mnot any arrangements^[[m
^[[31mwere necessary),^[[m^[[32mby using @code{AC_SYS_YEAR2038} and^[[m
^[[32mconfiguring without @option{--disable-year2038}.^[[m
^[[32mA future version of Autoconf might change the @code{AC_SYS_LARGEFILE}^[[m
^[[32mdefault to @code{--enable-year2038}; if and when that happens,^[[m
^[[32m@code{AC_SYS_LARGEFILE} and @code{AC_SYS_YEAR2038} will become equivalent.^[[m
^[[32m@xref{AC_SYS_YEAR2038}.^[[m

^[[32mSet^[[m the shell variable @code{ac_have_largefile}^[[31mwill be set^[[m to ^[[31m@samp{yes}; if not, it will be^[[m^[[32mto @samp{yes} or^[[m
^[[32m@code{no} depending on whether a wide @code{off_t} is available,^[[m
^[[32mregardless of whether arrangements were necessary.^[[m
^[[32mSimilarly,^[[m set ^[[32mthe shell variable @code{ac_have_year2038}^[[m to ^[[31m@samp{no}.^[[m

^[[31mPreprocessor^[[m^[[32m@code{yes}^[[m
^[[32mor @code{no} depending on whether a wide-enough @code{time_t} is available.^[[m

^[[32mDefine preprocessor^[[m macros^[[31mwill be defined^[[m if necessary to make ^[[31ma larger^[[m
^[[31m@code{off_t} available.  (For^[[m^[[32mtypes wider;^[[m
^[[32mfor^[[m example, on ^[[31mmany^[[m^[[32mGNU/Linux^[[m systems the ^[[31mmacro^[[m^[[32mmacros^[[m @code{_FILE_OFFSET_BITS}
^[[31mwill^[[m^[[32mand @code{_TIME_BITS} can^[[m be ^[[31mdefined.)^[[m^[[32mdefined.^[[m  Some of these macros^[[31monly^[[m work ^[[32monly^[[m if^[[31mthey are^[[m
defined before the first system header is included;
therefore, when using this macro in concert with^[[m
@code{AC_CONFIG_HEADERS}, make sure that @file{config.h} is included^[[m
before any system headers.^[[m

On ^[[31ma few older^[[m^[[32mobsolete IRIX^[[m systems, ^[[32malso change^[[m the output variable @code{CC}^[[31mwill also be^[[m
^[[31mchanged^[[m to
add^[[31mspecial^[[m compiler options^[[31mthat are^[[m needed ^[[31mto enable large^[[m^[[32mfor wide^[[m @code{off_t}.

Large-file support can be disabled by configuring with the^[[m
@option{--disable-largefile} ^[[31moption.  Note that this has^[[m^[[32moption, and year-2038 support can^[[m
^[[32mbe enabled and disabled via the @option{--enable-year2038} and^[[m
^[[32m@option{--disable-year2038} options.  These options have^[[m no effect on
systems where ^[[31m@code{off_t} is 64 bits or larger^[[m^[[32mtypes are wide enough^[[m by default.
^[[32mLarge-file support is required for year-2038 support: if you configure^[[m
^[[32mwith @option{--disable-largefile} on a platform with 32-bit^[[m
^[[32m@code{time_t}, then year-2038 support is not available.^[[m

Disabling large-file ^[[32mor year-2038^[[m support can have surprising effects,
such as causing functions like @code{readdir} and @code{stat} to fail
^[[32meven^[[m on ^[[32ma^[[m small ^[[31mfiles^[[m
^[[31m(because their @emph{inode numbers} are unrepresentable).^[[m^[[32mfile because its inode number or timestamp is out of range.^[[m

Regardless of whether you use this macro, portable programs should not^[[m
assume that any of the types listed above fit into a @code{long int}.^[[m
For example, it is not ^[[31mcorrect^[[m^[[32mportable^[[m to print an arbitrary @code{off_t} ^[[32mor^[[m
^[[32m@code{time_t}^[[m value @code{X} with @code{printf ("%ld", (long int) X)}.

^[[31mNote that the^[[m^[[32mThe^[[m standard C library functions @code{fseek} and @code{ftell}
do not use @code{off_t}.  If you need to use either of these functions,^[[m
you should use @code{AC_FUNC_FSEEKO} as well as @code{AC_SYS_LARGEFILE},^[[m
and then use their Posix replacements @code{fseeko} and ^[[31m@code{ftello},^[[m
^[[31mwhich @emph{do} use @code{off_t}, when available.^[[m^[[32m@code{ftello}.^[[m
@xref{AC_FUNC_FSEEKO}.

^[[31mAs of Autoconf 2.72,^[[m^[[32mWhen using^[[m @code{AC_SYS_LARGEFILE} ^[[31malso @emph{optionally}^[[m
^[[31marranges to enlarge @code{time_t}.  This^[[m^[[32min different packages that are linked^[[m
^[[32mtogether and that have interfaces that depend on the width of @code{off_t},^[[m
^[[32m@code{time_t} or related types, the simplest thing^[[m is to^[[31mmake it easier to build^[[m
^[[31mprograms that support timestamps after 2038; many^[[m configure ^[[31mscripts will^[[m
^[[31mnot need to be modified, only regenerated with newer Autoconf.  When^[[m^[[32mall^[[m
^[[32mcomponents the same way.  For example, if an application uses^[[m
@code{AC_SYS_LARGEFILE}^[[31mis used,^[[m and^[[31m@code{AC_SYS_YEAR2038}^[[m is ^[[31m@emph{not} used, @code{time_t} will normally^[[m^[[32mconfigured with^[[m
^[[32m@option{--enable-year2038}, libraries it links to with an @code{off_t}-^[[m
^[[32mor @code{time_t}-dependent interface should^[[m be ^[[31mleft at the system's^[[m
^[[31mdefault size, but^[[m^[[32mconfigured equivalently.^[[m
^[[32mAlternatively,^[[m you can ^[[31mrequest it be enlarged by configuring with the^[[m
^[[31m@option{--enable-year2038} option.  (When @code{AC_SYS_YEAR2038}^[[m^[[32mmodify libraries to support both 32- and 64-bit^[[m
^[[32minterfaces though this^[[m is ^[[31malso^[[m
^[[31mused,^[[m^[[32mmore work and few libraries other than the C^[[m
^[[32mlibrary itself are modified in this way.^[[m

^[[32mApplications and libraries should be configured compatibly.^[[m
^[[32mIf @code{off_t},^[[m @code{time_t} ^[[31mis enlarged^[[m^[[32mor related types appear in a library's^[[m
^[[32mpublic interface, enabling or disabling the library's large-file or^[[m
^[[32myear-2038 support may break binary compatibility with applications or^[[m
^[[32mwith other libraries.  Similarly,^[[m if ^[[31mpossible.  @xref{AC_SYS_YEAR2038}.)^[[m^[[32man application links to a such a^[[m
^[[32mlibrary, enabling or disabling the application's large-file support may^[[m
^[[32mbreak binary compatibility with that library.^[[m
@end defmac^[[m

@defmac AC_SYS_LARGEFILE_REQUIRED^[[m
@acindex{SYS_LARGEFILE_REQUIRED}^[[m
This macro has the same effect as @code{AC_SYS_LARGEFILE},^[[m
but also declares that the program being configured^[[m
^[[31m@emph{requires}^[[m^[[32mrequires^[[m support for large files.
If a large @code{off_t} is unavailable,^[[m
@command{configure} will error out.^[[m
The @option{--disable-largefile} option will not be available.^[[m
^[[31m@end defmac^[[m

^[[32mLarge-file and year-2038 support for applications and libraries should^[[m
^[[32mbe configured compatibly.  @xref{AC_SYS_LARGEFILE}.^[[m
^[[32m@end defmac^[[m

@anchor{AC_SYS_LONG_FILE_NAMES}^[[m
@defmac AC_SYS_LONG_FILE_NAMES^[[m
^[[36m@@ -8885,55 +8923,24 @@^[[m ^[[msystem.  If so, set the shell variable @code{ac_cv_sys_posix_termios} to^[[m
@anchor{AC_SYS_YEAR2038}^[[m
@defmac AC_SYS_YEAR2038^[[m
@acindex{SYS_YEAR2038}^[[m
^[[31m@cvindex _TIME_BITS^[[m
@cindex Year 2038^[[m
^[[31mIf the default @code{time_t} type^[[m^[[32mThis^[[m is ^[[31ma signed 32-bit integer,^[[m
^[[31mand therefore (assuming the usual Unix epoch) cannot represent^[[m
^[[31mtimestamps after mid-January of 2038, arrange to make a larger^[[m
^[[31m@code{time_t} available, if the system supports this.^[[m

^[[31mIf a large @code{time_t} is available (whether or not any arrangements^[[m
^[[31mwere necessary), the shell variable @code{ac_have_year2038} will be set^[[m
^[[31mto @samp{yes}; if not,^[[m^[[32mlike @code{AC_SYS_LARGEFILE} except^[[m it ^[[31mwill be set^[[m^[[32mdefaults^[[m to ^[[31m@samp{no}.^[[m

^[[31mPreprocessor macros will be defined if necessary to make a larger^[[m
^[[31m@code{time_t} available.  (For example, on some systems the macro^[[m
^[[31m@code{_TIME_BITS} will be defined.)  Some^[[m^[[32menabling^[[m
^[[32minstead^[[m of ^[[31mthese macros only work if^[[m
^[[31mthey are defined before the first system header is included; therefore,^[[m
^[[31mwhen using this macro in concert with @code{AC_CONFIG_HEADERS}, make^[[m
^[[31msure that @file{config.h} is included before any system headers.^[[m

^[[31mSupport^[[m^[[32mdisabling year-2038 support.  Year-2038 support^[[m for
^[[31mtimestamps after 2038 can be disabled by configuring with^[[m
^[[31mthe @option{--disable-year2038} option.  Note that this has no effect on^[[m
^[[31msystems where @code{time_t} is 64 bits or larger by default.^[[m
^[[31mIf this option is @emph{not} given,^[[m^[[32mapplications^[[m and ^[[31m@command{configure} fails to^[[m
^[[31mfind a way to enable a large @code{time_t}, but inspection of the^[[m
^[[31msystem suggests that this feature is available @emph{somehow}, it will^[[m
^[[31merror out.^[[m

^[[31mRegardless of whether you use this macro, portable programs^[[m^[[32mlibraries^[[m should ^[[31mnot^[[m
^[[31massume that @code{time_t} fits into @code{long int}.  For example, it is^[[m
^[[31mnot correct to print an arbitrary @code{time_t} value @code{X} with^[[m
^[[31m@code{printf ("%ld", (long int) X)}.^[[m

^[[31m@strong{Caution:} If you are developing a shared library, and^[[m
^[[31m@code{time_t} appears anywhere in your library's public interface, use^[[m
^[[31mof this macro may break binary compatibility with older executables.^[[m^[[32mbe configured compatibly.^[[m
^[[32m@xref{AC_SYS_LARGEFILE}.^[[m
@end defmac^[[m

@defmac AC_SYS_YEAR2038_REQUIRED^[[m
@acindex{SYS_YEAR2038_REQUIRED}^[[m
This macro has the same effect as @code{AC_SYS_YEAR2038},^[[m
but also declares that the program being configured^[[m
^[[31m@emph{requires}^[[m^[[32mrequires^[[m support for timestamps after mid-January of 2038.
If a large @code{time_t} is unavailable,^[[m
@command{configure} will ^[[31m@emph{unconditionally}^[[m^[[32munconditionally^[[m error ^[[31mout^[[m
^[[31m(unlike the behavior of @code{AC_SYS_YEAR2038}).^[[m^[[32mout.^[[m
The @option{--disable-year2038} option will not be available.^[[m

^[[31m@strong{Caution:} If you are developing a shared library,^[[m^[[32mYear-2038 support for applications^[[m and ^[[31m@code{time_t} appears anywhere in your library's public interface, use^[[m
^[[31mof this macro may break binary compatibility with older executables.^[[m^[[32mlibraries should be configured^[[m
^[[32mcompatibly.  @xref{AC_SYS_YEAR2038}.^[[m
@end defmac^[[m

@node C and Posix Variants^[[m

^ permalink raw reply related	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-12-30 22:12                             ` Paul Eggert
@ 2022-12-30 22:20                               ` Sam James
  2023-01-20  9:56                               ` Paul Eggert
  1 sibling, 0 replies; 75+ messages in thread
From: Sam James @ 2022-12-30 22:20 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Zack Weinberg, Florian Weimer, wookey, autoconf-patches, c-std-porting

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



> On 30 Dec 2022, at 22:12, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 12/28/22 20:02, Zack Weinberg wrote:
> 
>> Please revert that part of your follow-up patch.
> OK, I reverted all that patch, except for the further changes you requested, plus some minor quoting and version-number fixes in comments.
> 
>> 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?
> 
> Sure, I'm attaching a proposed patch to Autoconf master documentation in two forms. The first is a simple "git format-patch" file; the second is the output of "git diff --color=always --word-diff=color".
> 
>> 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.
> 
> Although I don't think this feature is useful, I don't have to use it so we can leave it in.
> 
> Here's why I'm not planning to use it. I help maintain (for example) GNU Tar, where file sizes and timestamps are crucial. But if I change GNU Tar to use AC_SYS_LARGEFILE_REQUIRED, people won't be able to build GNU Tar on ancient platforms that support file sizes only up to 2 GiB. Nobody will benefit from this: the very few users who'd care (computer museum curators, say) already know their systems are limited, and will simply build older versions of GNU Tar that don't use AC_SYS_LARGEFILE_REQUIRED, or will edit away the "_REQUIRED" before building. So adding the _REQUIRED will harm a very small set of users, will increase my maintenance burden a bit, and will benefit essentially nobody.
> 
> To put it another way: we've all gotten by without needing AC_SYS_LARGEFILE_REQUIRED for 25 years, and there's no reason for us to start needing it now even though it's imperative for any serious application that deals with files.
> 

I think it's useful as a primitive to have (some projects may want to use it to clearly define what they don't support) but I understand why you won't be using it for those projects.

> The situation for AC_SYS_YEAR2038_REQUIRED will likely be similar.
> 
> As things currently stand, I plan to use AC_SYS_YEAR2038 instead of AC_SYS_LARGEFILE in GNU Tar and similar applications. (They'll use Gnulib so they'll get Autoconf 2.72-compatible AC_SYS_YEAR2038 even with older Autoconf.) Perhaps other maintainers will want to use the *_REQUIRED macros, but as far as I can see my advice will be to avoid them as being more trouble than they're worth.
> 
> 
>> 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
> 
> Unfortunately the documenation currently on Autoconf master makes for a lot of confusion and misimpression. It's more important for documentation to agree with what the code actually does, than for it to present an abstract picture of what we'd like the code to do eventually. The abovementioned patches fix this.
> 

I think we might benefit from a page on the glibc wiki or something describing our broad vision & what distributions and upstreams need to know but that's not a blocker and it's a nice-to-have for the future.

I'm going to keep banging on about this topic once we've sorted out autoconf, so I don't think there's a risk in us forgetting about it.

> 
>> In the new year, I can look into the possibility of decoupling the
>> macros’ implementations.
> 
> I don't see how that would be possible. On the only platforms where --enable-year2038 matters, you cannot have year-2038 support without also having large-file support.
> 
> The platforms in question are glibc 2.34+ on 32-bit ARM and x86. The glibc community considered making the two things orthogonal but rejected that alternative as being considerably more trouble than it was worth. I think it unlikely for other 32-bit OS suppliers to decide differently.
> 
> 
>> I think you’re still writing documentation with application-colored
>> glasses on, making it sound like --enable-year2038 has no negative
>> implications whatsoever.
> 
> That's a bit unfair. The proposed documentation does mention the compatibility implications; it merely uses the same level of caution for both --enable-largefile and --enable-year2038, and it doesn't overhype the time_t issue with an undeserved big "Caution:" inbold.
> 
> Although I plead guilty in being close to users (many who need year 2038 support now for obvious reasons) I'm well aware of the implication for libraries. When I implemented AC_SYS_LARGEFILE back in the 1990s, there were similar compatibility concerns with off_t that I also took seriously. In the end, the need for large-file support outweighed the backward-compatibility hassles and AC_SYS_LARGEFILE has been a success in that people have used AC_SYS_LARGEFILE for years and sure there are occasionally glitches but the benefits far outweigh the costs.
> 
> AC_SYS_YEAR2038 will be similar. Not identical of course, but similar. We've done this sort of thing before and have experience.
> 

I agree broadly, but my concern is mainly in that until recently, most distributions (and upstream maintainers) were quite bad at finding out when ABI breaks occur. But things like libabigail's abidiff make this a lot easier.

Of course, the nature of ABI breakage may just mean it's a crash or misbehaviour which somebody never reports. But I don't want to keep rehashing these bits, I agree with your point below that we need to move forward.

> 
>> 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.”
> 
> The proposed documentation patches contain a simple plan for how Autoconf can plausibly survive through the year 2038. Is there a better plan? If so, I'd like to hear it. If not, then let's use this plan. Given the long delay between Autoconf versions and end uses of downstream software, we need a plan now, not years from now. The plan doesn't have to be perfect, nor does it need to be cast in stone. But there needs to be a plan.

I'm happy with the patch as attached. Thank you for your perseverance. Unfortunately, I've been running into people who are resistant
to even fix C23 issues in configure scripts in their own code because "autoconf is still generating broken scripts, so I'm keen to
move past the time64/LFS blockers if we can. I think this does the job.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-12-30 22:12                             ` Paul Eggert
  2022-12-30 22:20                               ` Sam James
@ 2023-01-20  9:56                               ` Paul Eggert
  2023-02-02  6:43                                 ` Sam James
  1 sibling, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2023-01-20  9:56 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Florian Weimer, sam, wookey, autoconf-patches, c-std-porting

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

On 2022-12-30 14:12, Paul Eggert wrote:
> I'm attaching a proposed patch to Autoconf master documentation in two 
> forms.
Zack, any further thoughts on that Autoconf patch? If not, I'm inclined 
to install it as it doesn't change behavior, only documentation, and Sam 
wrote that he was happy with the patch. For convenience I'm reattaching 
the same patch to this email.

Also, is there anything else blocking a new Autoconf release?

[-- Attachment #2: 0001-Improve-year-2038-documentation.patch --]
[-- Type: text/x-patch, Size: 16832 bytes --]

From 3e9f1159ae9145c50d048a74422dd8464a6a8f6f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 30 Dec 2022 12:48:39 -0800
Subject: [PATCH] Improve year-2038 documentation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* NEWS, doc/autoconf.texi (System Services):
Improve documentation for behavior of largefile and year-2038 support.
Say that in the current implementation, year-2038 support
requires largefile support.  Say that year-2038 support
matters only for GNU/Linux glibc 2.34+ on 32-bit x86 and ARM.
Prefer brevity when this does not hurt understandability;
for example, prefer active to passive voice.
Prefer “wider” to “larger” when talking about the number of
bits in an integer, as this terminology is more standard.
Tone down the wording in warnings about enabling year-2038 support,
use similar wording in warnings about enabling largefile support,
and warn also about disabling largefile and year-2038 support.
No need for @emph.  Also mention rlim_t.
Be a bit more careful about saying “2 GiB” rather than “2 GB”.
Mention that a future version of Autoconf might change
AC_SYS_LARGEFILE to default to --enable-year2038, since
something has gotta happen before 2038.
Coalesce descriptions of --enable-largefile and --enable-year2038
to simplify documentation.  Mention that the only system where
AC_SYS_LARGEFILE changes CC is IRIX and that these systems
are obsolete.  Say that ‘stat’ can fail due to time_t
overflow.  Say that you can’t portably print time_t with %ld.
Say that binary compatibilty problems also can occur when one
library is linking to amother; it’s not just apps vs libraries.
Mention the possibility of modifying libraries to support both
32- and 64-bit interfaces.  Warn more consistently about
ABI compatibility issues, but put the bulk of this text
in one location that the other locations refer to.
---
 NEWS              |  57 ++++++++--------
 doc/autoconf.texi | 165 ++++++++++++++++++++++++----------------------
 2 files changed, 113 insertions(+), 109 deletions(-)

diff --git a/NEWS b/NEWS
index eafd7d69..0f71628d 100644
--- a/NEWS
+++ b/NEWS
@@ -27,36 +27,33 @@ GNU Autoconf NEWS - User visible changes.
 
 ** New features
 
-*** New macros AC_SYS_YEAR2038 and AC_SYS_YEAR2038_REQUIRED.
-  These macros attempt to enlarge time_t to 64 bits, on systems where
-  it has historically been only 32 bits wide, and therefore (assuming
-  the usual Unix epoch) cannot represent dates after mid-January of
-  2038 (hence the names).  The difference between the two is that
-  AC_SYS_YEAR2038_REQUIRED unconditionally causes 'configure' to error
-  out if 64-bit time_t is not available.
-
-  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.
-
-  Library authors should be cautious about adding these macros to
-  their configure scripts; they can break binary backward compatibility.
-
-*** New macro AC_SYS_LARGEFILE_REQUIRED.
-  This macro is the same as the existing AC_SYS_LARGEFILE except that
-  it will cause 'configure' to error out if 64-bit off_t is not available,
-  and it does not provide a --disable-largefile option.
-
-*** AC_SYS_LARGEFILE now optionally arranges to enlarge time_t.
-  As an experimental measure to make it easier to rebuild old programs
-  with support for dates after Jan 2038, if you regenerate any configure
-  script that uses AC_SYS_LARGEFILE (but not AC_SYS_YEAR2038) using
-  Autoconf 2.72, it will gain an --enable-year2038 option.  When the
-  program is configured with this option, time_t will be enlarged if
-  possible, as if AC_SYS_YEAR2038 had been used.
-
-  Using this option in a library build also potentially breaks binary
-  backward compatibility.
+*** New macro AC_SYS_YEAR2038.
+  This causes 'configure' to widen time_t if possible on systems where
+  time_t by default cannot represent file and other timestamps after
+  January 2038.  Widening is possible only on 32-bit GNU/Linux x86 and
+  ARM systems with glibc 2.34 or later.  To prevent widening,
+  configure with --disable-year2038.
+
+  This macro also has the effects as AC_SYS_LARGEFILE, because in
+  practice time_t cannot be widened without large-file sypport.
+
+  Application and library builders should take care that packages
+  configured with --enable-year2038 and --disable-year2038 options
+  are configured consistently, to avoid breaking binary compatibility.
+  This is similar to longstanding consistency requirements with
+  --enable-largefile and --disable-largefile.
+
+*** AC_SYS_LARGEFILE now optionally arranges to widen time_t.
+  It now acts like AC_SYS_YEAR2038, except 'configure' defaults to
+  --disable-year2038 unless AC_SYS_YEAR2038 is also present.
+  As with AC_SYS_YEAR2038, application and library builders should
+  configure consistently.
+
+*** New macros AC_SYS_LARGEFILE_REQUIRED and AC_SYS_YEAR2038_REQUIRED.
+  These act like AC_SYS_LARGEFILE and AC_SYS_YEAR2038 respectively,
+  except that they require large-file and year-2038 support respectively.
+  As with AC_SYS_YEAR2038, application and library builders should
+  configure consistently.
 
 *** AC_USE_SYSTEM_EXTENSIONS now enables C23 Annex F extensions
   by defining __STDC_WANT_IEC_60559_EXT__.
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index df96280b..ce214284 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -8798,71 +8798,109 @@ if the system supports @samp{#!}, @samp{no} if not.
 @defmac AC_SYS_LARGEFILE
 @acindex{SYS_LARGEFILE}
 @cvindex _FILE_OFFSET_BITS
+@cvindex _TIME_BITS
 @ovindex CC
 @cindex Large file support
 @cindex LFS
-If the default @code{off_t} type is a 32-bit integer, and therefore
-cannot be used to work with files larger than 4 gigabytes, arrange to
-make a larger @code{off_t} available, if the system supports this.
-Several other types related to the sizes of files and file systems will
-also be enlarged: @code{ino_t}, @code{blkcnt_t}, @code{fsblkcnt_t},
-@code{fsfilcnt_t}, and possibly @code{dev_t}.
-
-If a large @code{off_t} is available (whether or not any arrangements
-were necessary), the shell variable @code{ac_have_largefile} will be set
-to @samp{yes}; if not, it will be set to @samp{no}.
-
-Preprocessor macros will be defined if necessary to make a larger
-@code{off_t} available.  (For example, on many systems the macro
-@code{_FILE_OFFSET_BITS} will be defined.)  Some of these macros only
-work if they are defined before the first system header is included;
+If the default @code{off_t} type is a 32-bit integer,
+and therefore cannot be used with files 2 GiB or larger,
+make a wider @code{off_t} available if the system supports it.
+Similarly, widen other types related to sizes of files and file systems
+if possible.  These types may include @code{blkcnt_t}, @code{dev_t},
+@code{ino_t}, @code{fsblkcnt_t}, @code{fsfilcnt_t}, and @code{rlim_t}.
+
+Also, arrange for a @command{configure} option @code{--enable-year2038}
+to request widening the type @code{time_t} as needed to represent file
+wand other timestamps after January 2038.  This widening is possible
+only on 32-bit GNU/Linux x86 and ARM systems with glibc 2.34 or later.
+If year-2038 support is requested but @command{configure} fails to find a way
+to widen @code{time_t} and inspection of the system suggests that
+this feature is available somehow, @command{configure} will error out.
+If you want the default to be @code{--enable-year2038}, you can use
+@code{AC_SYS_YEAR2038} instead of @code{AC_SYS_LARGEFILE}.
+In other words, older packages that have long used @code{AC_SYS_LARGEFILE}
+can have year-2038 support on 32-bit GNU/Linux x86 and ARM systems either by
+regenerating @file{configure} with current Autoconf and configuring with
+@option{--enable-year2038}, or by using @code{AC_SYS_YEAR2038} and
+configuring without @option{--disable-year2038}.
+A future version of Autoconf might change the @code{AC_SYS_LARGEFILE}
+default to @code{--enable-year2038}; if and when that happens,
+@code{AC_SYS_LARGEFILE} and @code{AC_SYS_YEAR2038} will become equivalent.
+@xref{AC_SYS_YEAR2038}.
+
+Set the shell variable @code{ac_have_largefile} to to @samp{yes} or
+@code{no} depending on whether a wide @code{off_t} is available,
+regardless of whether arrangements were necessary.
+Similarly, set the shell variable @code{ac_have_year2038} to @code{yes}
+or @code{no} depending on whether a wide-enough @code{time_t} is available.
+
+Define preprocessor macros if necessary to make types wider;
+for example, on GNU/Linux systems the macros @code{_FILE_OFFSET_BITS}
+and @code{_TIME_BITS} can be defined.  Some of these macros work only if
+defined before the first system header is included;
 therefore, when using this macro in concert with
 @code{AC_CONFIG_HEADERS}, make sure that @file{config.h} is included
 before any system headers.
 
-On a few older systems, the output variable @code{CC} will also be
-changed to add special compiler options that are needed to enable large
-@code{off_t}.
+On obsolete IRIX systems, also change the output variable @code{CC} to
+add compiler options needed for wide @code{off_t}.
 
 Large-file support can be disabled by configuring with the
-@option{--disable-largefile} option.  Note that this has no effect on
-systems where @code{off_t} is 64 bits or larger by default.  Disabling
-large-file support can have surprising effects, such as causing
-functions like @code{readdir} and @code{stat} to fail on small files
-(because their @emph{inode numbers} are unrepresentable).
+@option{--disable-largefile} option, and year-2038 support can
+be enabled and disabled via the @option{--enable-year2038} and
+@option{--disable-year2038} options.  These options have no effect on
+systems where types are wide enough by default.
+Large-file support is required for year-2038 support: if you configure
+with @option{--disable-largefile} on a platform with 32-bit
+@code{time_t}, then year-2038 support is not available.
+
+Disabling large-file or year-2038 support can have surprising effects,
+such as causing functions like @code{readdir} and @code{stat} to fail
+even on a small file because its inode number or timestamp is out of range.
 
 Regardless of whether you use this macro, portable programs should not
 assume that any of the types listed above fit into a @code{long int}.
-For example, it is not correct to print an arbitrary @code{off_t} value
-@code{X} with @code{printf ("%ld", (long int) X)}.
+For example, it is not portable to print an arbitrary @code{off_t} or
+@code{time_t} value @code{X} with @code{printf ("%ld", (long int) X)}.
 
-Note that the standard C library functions @code{fseek} and @code{ftell}
+The standard C library functions @code{fseek} and @code{ftell}
 do not use @code{off_t}.  If you need to use either of these functions,
 you should use @code{AC_FUNC_FSEEKO} as well as @code{AC_SYS_LARGEFILE},
-and then use their Posix replacements @code{fseeko} and @code{ftello},
-which @emph{do} use @code{off_t}, when available.  @xref{AC_FUNC_FSEEKO}.
-
-As of Autoconf 2.72, @code{AC_SYS_LARGEFILE} also @emph{optionally}
-arranges to enlarge @code{time_t}.  This is to make it easier to build
-programs that support timestamps after 2038; many configure scripts will
-not need to be modified, only regenerated with newer Autoconf.  When
-@code{AC_SYS_LARGEFILE} is used, and @code{AC_SYS_YEAR2038} is
-@emph{not} used, @code{time_t} will normally be left at the system's
-default size, but you can request it be enlarged by configuring with the
-@option{--enable-year2038} option.  (When @code{AC_SYS_YEAR2038} is also
-used, @code{time_t} is enlarged if possible.  @xref{AC_SYS_YEAR2038}.)
+and then use their Posix replacements @code{fseeko} and @code{ftello}.
+@xref{AC_FUNC_FSEEKO}.
+
+When using @code{AC_SYS_LARGEFILE} in different packages that are linked
+together and that have interfaces that depend on the width of @code{off_t},
+@code{time_t} or related types, the simplest thing is to configure all
+components the same way.  For example, if an application uses
+@code{AC_SYS_LARGEFILE} and is configured with
+@option{--enable-year2038}, libraries it links to with an @code{off_t}-
+or @code{time_t}-dependent interface should be configured equivalently.
+Alternatively, you can modify libraries to support both 32- and 64-bit
+interfaces though this is more work and few libraries other than the C
+library itself are modified in this way.
+
+Applications and libraries should be configured compatibly.
+If @code{off_t}, @code{time_t} or related types appear in a library's
+public interface, enabling or disabling the library's large-file or
+year-2038 support may break binary compatibility with applications or
+with other libraries.  Similarly, if an application links to a such a
+library, enabling or disabling the application's large-file support may
+break binary compatibility with that library.
 @end defmac
 
 @defmac AC_SYS_LARGEFILE_REQUIRED
 @acindex{SYS_LARGEFILE_REQUIRED}
 This macro has the same effect as @code{AC_SYS_LARGEFILE},
 but also declares that the program being configured
-@emph{requires} support for large files.
+requires support for large files.
 If a large @code{off_t} is unavailable,
 @command{configure} will error out.
 The @option{--disable-largefile} option will not be available.
-@end defmac
 
+Large-file and year-2038 support for applications and libraries should
+be configured compatibly.  @xref{AC_SYS_LARGEFILE}.
+@end defmac
 
 @anchor{AC_SYS_LONG_FILE_NAMES}
 @defmac AC_SYS_LONG_FILE_NAMES
@@ -8885,55 +8923,24 @@ system.  If so, set the shell variable @code{ac_cv_sys_posix_termios} to
 @anchor{AC_SYS_YEAR2038}
 @defmac AC_SYS_YEAR2038
 @acindex{SYS_YEAR2038}
-@cvindex _TIME_BITS
 @cindex Year 2038
-If the default @code{time_t} type is a signed 32-bit integer,
-and therefore (assuming the usual Unix epoch) cannot represent
-timestamps after mid-January of 2038, arrange to make a larger
-@code{time_t} available, if the system supports this.
-
-If a large @code{time_t} is available (whether or not any arrangements
-were necessary), the shell variable @code{ac_have_year2038} will be set
-to @samp{yes}; if not, it will be set to @samp{no}.
-
-Preprocessor macros will be defined if necessary to make a larger
-@code{time_t} available.  (For example, on some systems the macro
-@code{_TIME_BITS} will be defined.)  Some of these macros only work if
-they are defined before the first system header is included; therefore,
-when using this macro in concert with @code{AC_CONFIG_HEADERS}, make
-sure that @file{config.h} is included before any system headers.
-
-Support for timestamps after 2038 can be disabled by configuring with
-the @option{--disable-year2038} option.  Note that this has no effect on
-systems where @code{time_t} is 64 bits or larger by default.
-If this option is @emph{not} given, and @command{configure} fails to
-find a way to enable a large @code{time_t}, but inspection of the
-system suggests that this feature is available @emph{somehow}, it will
-error out.
-
-Regardless of whether you use this macro, portable programs should not
-assume that @code{time_t} fits into @code{long int}.  For example, it is
-not correct to print an arbitrary @code{time_t} value @code{X} with
-@code{printf ("%ld", (long int) X)}.
-
-@strong{Caution:} If you are developing a shared library, and
-@code{time_t} appears anywhere in your library's public interface, use
-of this macro may break binary compatibility with older executables.
+This is like @code{AC_SYS_LARGEFILE} except it defaults to enabling
+instead of disabling year-2038 support.  Year-2038 support for
+applications and libraries should be configured compatibly.
+@xref{AC_SYS_LARGEFILE}.
 @end defmac
 
 @defmac AC_SYS_YEAR2038_REQUIRED
 @acindex{SYS_YEAR2038_REQUIRED}
 This macro has the same effect as @code{AC_SYS_YEAR2038},
 but also declares that the program being configured
-@emph{requires} support for timestamps after mid-January of 2038.
+requires support for timestamps after mid-January of 2038.
 If a large @code{time_t} is unavailable,
-@command{configure} will @emph{unconditionally} error out
-(unlike the behavior of @code{AC_SYS_YEAR2038}).
+@command{configure} will unconditionally error out.
 The @option{--disable-year2038} option will not be available.
 
-@strong{Caution:} If you are developing a shared library, and
-@code{time_t} appears anywhere in your library's public interface, use
-of this macro may break binary compatibility with older executables.
+Year-2038 support for applications and libraries should be configured
+compatibly.  @xref{AC_SYS_YEAR2038}.
 @end defmac
 
 @node C and Posix Variants
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-01-20  9:56                               ` Paul Eggert
@ 2023-02-02  6:43                                 ` Sam James
  2023-02-02 23:15                                   ` time for Autoconf 2.72 (was: On time64 and Large File Support) Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Sam James @ 2023-02-02  6:43 UTC (permalink / raw)
  To: Paul Eggert, Zack Weinberg
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

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



> On 20 Jan 2023, at 09:56, Paul Eggert <eggert@cs.ucla.edu> wrote:
> 
> On 2022-12-30 14:12, Paul Eggert wrote:
>> I'm attaching a proposed patch to Autoconf master documentation in two forms.
> Zack, any further thoughts on that Autoconf patch? If not, I'm inclined to install it as it doesn't change behavior, only documentation, and Sam wrote that he was happy with the patch. For convenience I'm reattaching the same patch to this email.
> 
> Also, is there anything else blocking a new Autoconf release?<0001-Improve-year-2038-documentation.patch>

FWIW, Clang 16 branched a week ago. Unfortunately, I think we've missed the Debian freeze I think, but it is what it is there
(was hoping to get it in there so we could benefit from the large number of people who make dist tarballs on Debian).

Unfortunately, the current issues from autoconf continue to pose a lot of noise for me during the C porting
work. Regenerating from master cleans things up a tonne though.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-02-02  6:43                                 ` Sam James
@ 2023-02-02 23:15                                   ` Paul Eggert
  2023-02-02 23:17                                     ` Zack Weinberg
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2023-02-02 23:15 UTC (permalink / raw)
  To: Sam James, Zack Weinberg
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

On 2/1/23 22:43, Sam James wrote:
> Unfortunately, I think we've missed the Debian freeze I think, but it is what it is there
> (was hoping to get it in there so we could benefit from the large number of people who make dist tarballs on Debian).

Oh well. As you say, it is what it is.

Since there's been no comment about that documentation change I 
installed it in Autoconf master on Savannah. I also installed the result 
of a 'make fetch'.

As far as I know, the next Autoconf release is good to go. Unfortunately 
I can't test Autoconf as well as Zack tested it. However, it appears 
that releasing what we've got would be better than not releasing it so 
I'm hoping that we can release Autoconf 2.72 soon, even if it's not as 
well tested as Autoconf 2.71 was.

Comments welcome.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-02-02 23:15                                   ` time for Autoconf 2.72 (was: On time64 and Large File Support) Paul Eggert
@ 2023-02-02 23:17                                     ` Zack Weinberg
  2023-02-03  5:49                                       ` Sam James
  0 siblings, 1 reply; 75+ messages in thread
From: Zack Weinberg @ 2023-02-02 23:17 UTC (permalink / raw)
  To: Paul Eggert, Sam James
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

Due to a series of crises with my day job, the earliest I can promise to do _anything_ Autoconf related is early March. If you have time to make a release before then, please do not wait for me.

zw

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-02-02 23:17                                     ` Zack Weinberg
@ 2023-02-03  5:49                                       ` Sam James
  2023-02-03 12:43                                         ` time for Autoconf 2.72 Bruno Haible
       [not found]                                         ` <CAObJKZp2CCRR46-X9NYaRES7eDCVyoJ0xv=u4aSG2KeQv4vtjA@mail.gmail.com>
  0 siblings, 2 replies; 75+ messages in thread
From: Sam James @ 2023-02-03  5:49 UTC (permalink / raw)
  To: Zack Weinberg, Paul Eggert
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

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



> On 2 Feb 2023, at 23:17, Zack Weinberg <zack@owlfolio.org> wrote:
> 
> Due to a series of crises with my day job, the earliest I can promise to do _anything_ Autoconf related is early March. If you have time to make a release before then, please do not wait for me.
> 

Sorry to hear Zack, hope you're doing ok. I think your input on the issues we've been talking about has been enough
for us to each a good position for now.

Paul in particular, please let me know if there's something I can do to help. I'm already giving it the standard rounds of usage
in Gentoo. Perhaps we could tag an RC and shove it into the platform-testers list? It's non-commital so while I'd like
to move forward before March for the final release, if in the event you didn't feel comfortable doing that,
we'd at least have made some progress.

Best,
sa

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72
  2023-02-03  5:49                                       ` Sam James
@ 2023-02-03 12:43                                         ` Bruno Haible
       [not found]                                         ` <CAObJKZp2CCRR46-X9NYaRES7eDCVyoJ0xv=u4aSG2KeQv4vtjA@mail.gmail.com>
  1 sibling, 0 replies; 75+ messages in thread
From: Bruno Haible @ 2023-02-03 12:43 UTC (permalink / raw)
  To: Zack Weinberg, Paul Eggert, Sam James
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

Sam James wrote:
> Perhaps we could tag an RC and shove it into the platform-testers list?

platform-testers is not a wide enough audience. I'd suggest to write to
gnu-prog-discuss and ask some of the maintainers there to try to upgrade
their packages to the Autoconf RC.

Bruno




^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
       [not found]                                         ` <CAObJKZp2CCRR46-X9NYaRES7eDCVyoJ0xv=u4aSG2KeQv4vtjA@mail.gmail.com>
@ 2023-02-27  2:30                                           ` Sam James
  2023-03-17 23:47                                             ` Sam James
  0 siblings, 1 reply; 75+ messages in thread
From: Sam James @ 2023-02-27  2:30 UTC (permalink / raw)
  To: Frederic Berat, Paul Eggert
  Cc: Zack Weinberg, Florian Weimer, Wookey, autoconf-patches, c-std-porting

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



> On 3 Feb 2023, at 07:43, Frederic Berat <fberat@redhat.com> wrote:
> 
> Hi,
> 
> I'm also in favor of an RC release, I can then rebuild Fedora packages using the tarball from the tester list and do some kind of A/B testing.
> 
Paul, would you be willing to try this? I don't think much work should be needed (famous last words) other than the tag & uploading it,
given the target audience  - that is, I wouldn't worry over testing it extensively given that's the point of the RC for now, and that can always be done
before a subsequent RC or final release.

Autoconf is currently one of the big barriers to making more progress on the C porting front, unfortunately and trying to explain
to upstreams that some issues are ok-but-will-be-fixed-later ends up being confusing.

If you're not able to look into an RC, I can try ship a snapshot in Gentoo which won't be generally available to users, but
ask for eager users to test, but that won't help with other distros or interested parties.

I'm happy to do the work if someone can tell me what needs doing, as well.

I'm sorry to ask directly, it's just that it keeps coming up in discussions with upstreams & package maintainers.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2022-11-11  8:38 On time64 and Large File Support Sam James
                   ` (2 preceding siblings ...)
  2022-11-11 10:25 ` Richard Purdie
@ 2023-03-01 22:38 ` Eric Blake
  2023-03-02  0:29   ` Demi Marie Obenour
  2023-03-02  8:30   ` Richard W.M. Jones
  3 siblings, 2 replies; 75+ messages in thread
From: Eric Blake @ 2023-03-01 22:38 UTC (permalink / raw)
  To: Sam James
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, berrange, rjones

[replying to the original post, because I'm not sure where else in the
more recent activity on this thread would be more appropriate]

On Fri, Nov 11, 2022 at 08:38:18AM +0000, Sam James wrote:
> Hi all,
> 
> In Gentoo, we've been planning out what we should do for time64 on glibc [0]
> and concluded that we need some support in glibc for a newer option. I'll outline
> why below.
>
...
> 
> Indeed, the gnulib version of change #2 is exactly how we ended up with
> wget/gnutls breaking [1]. I feel this shows that the only approach
> "supported" by glibc right now is untenable.

> [1] https://bugs.gentoo.org/828001

Now Fedora is also being hit by the gnutls ABI change due to time_t in
public interfaces being silently changed.  From an IRC conversation I
had with Dan Berrange and Rich Jones (I think Rich mean i686 below):

<danpb> rjones (IRC): oh wow, the certificates created on i696 are not quite right .....
<danpb>         Validity:
<danpb>                 Not Before: Sat Sep 05 00:23:57 UTC 2703
<danpb>                 Not After: Sun Sep 06 00:23:57 UTC 2703
<danpb> just a few years too early
<danpb> i think this is looking like a gnutls regression,   downgrading gnutls makes it work
...
<danpb> rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc
<danpb> gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage
<danpb> but the very same call done from a demo program returns the right answer
...
<danpb> OMG, gnulib-- has silently changed gnutls to use 64-bit time_t
<danpb> ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters
<danpb> so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t
<danpb> this is utterly insane

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-01 22:38 ` Eric Blake
@ 2023-03-02  0:29   ` Demi Marie Obenour
  2023-03-02  9:04     ` Daniel P. Berrangé
  2023-03-02  8:30   ` Richard W.M. Jones
  1 sibling, 1 reply; 75+ messages in thread
From: Demi Marie Obenour @ 2023-03-02  0:29 UTC (permalink / raw)
  To: Eric Blake, Sam James
  Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, berrange, rjones


[-- Attachment #1.1.1: Type: text/plain, Size: 2048 bytes --]

On 3/1/23 17:38, Eric Blake wrote:
> [replying to the original post, because I'm not sure where else in the
> more recent activity on this thread would be more appropriate]
> 
> On Fri, Nov 11, 2022 at 08:38:18AM +0000, Sam James wrote:
>> Hi all,
>>
>> In Gentoo, we've been planning out what we should do for time64 on glibc [0]
>> and concluded that we need some support in glibc for a newer option. I'll outline
>> why below.
>>
> ...
>>
>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>> wget/gnutls breaking [1]. I feel this shows that the only approach
>> "supported" by glibc right now is untenable.
> 
>> [1] https://bugs.gentoo.org/828001
> 
> Now Fedora is also being hit by the gnutls ABI change due to time_t in
> public interfaces being silently changed.  From an IRC conversation I
> had with Dan Berrange and Rich Jones (I think Rich mean i686 below):
> 
> <danpb> rjones (IRC): oh wow, the certificates created on i696 are not quite right .....
> <danpb>         Validity:
> <danpb>                 Not Before: Sat Sep 05 00:23:57 UTC 2703
> <danpb>                 Not After: Sun Sep 06 00:23:57 UTC 2703
> <danpb> just a few years too early
> <danpb> i think this is looking like a gnutls regression,   downgrading gnutls makes it work
> ...
> <danpb> rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc
> <danpb> gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage
> <danpb> but the very same call done from a demo program returns the right answer
> ...
> <danpb> OMG, gnulib-- has silently changed gnutls to use 64-bit time_t
> <danpb> ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters
> <danpb> so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t
> <danpb> this is utterly insane

Time to do a mass rebuild and mass SONAME bump of everything shipped as 32-bits?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4963 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-01 22:38 ` Eric Blake
  2023-03-02  0:29   ` Demi Marie Obenour
@ 2023-03-02  8:30   ` Richard W.M. Jones
  1 sibling, 0 replies; 75+ messages in thread
From: Richard W.M. Jones @ 2023-03-02  8:30 UTC (permalink / raw)
  To: Eric Blake
  Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	Paul Eggert, berrange, Daiki Ueno

On Wed, Mar 01, 2023 at 04:38:59PM -0600, Eric Blake wrote:
> [replying to the original post, because I'm not sure where else in the
> more recent activity on this thread would be more appropriate]
> 
> On Fri, Nov 11, 2022 at 08:38:18AM +0000, Sam James wrote:
> > Hi all,
> > 
> > In Gentoo, we've been planning out what we should do for time64 on glibc [0]
> > and concluded that we need some support in glibc for a newer option. I'll outline
> > why below.
> >
> ...
> > 
> > Indeed, the gnulib version of change #2 is exactly how we ended up with
> > wget/gnutls breaking [1]. I feel this shows that the only approach
> > "supported" by glibc right now is untenable.
> 
> > [1] https://bugs.gentoo.org/828001
> 
> Now Fedora is also being hit by the gnutls ABI change due to time_t in
> public interfaces being silently changed.  From an IRC conversation I
> had with Dan Berrange and Rich Jones (I think Rich mean i686 below):
> 
> <danpb> rjones (IRC): oh wow, the certificates created on i696 are not quite right .....
> <danpb>         Validity:
> <danpb>                 Not Before: Sat Sep 05 00:23:57 UTC 2703
> <danpb>                 Not After: Sun Sep 06 00:23:57 UTC 2703
> <danpb> just a few years too early
> <danpb> i think this is looking like a gnutls regression,   downgrading gnutls makes it work
> ...
> <danpb> rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc
> <danpb> gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage
> <danpb> but the very same call done from a demo program returns the right answer
> ...
> <danpb> OMG, gnulib-- has silently changed gnutls to use 64-bit time_t
> <danpb> ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters
> <danpb> so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t
> <danpb> this is utterly insane

For context, we first noticed that qemu tests were failing on i686
with lots of TLS-related errors.  qemu uses GnuTLS.  eg:

Summary of Failures:
124/658 qemu:unit / test-crypto-tlscredsx509                                      ERROR           2.42s   killed by signal 6 SIGABRT
202/658 qemu:unit / test-io-channel-tls                                           ERROR           1.47s   killed by signal 6 SIGABRT
125/658 qemu:unit / test-crypto-tlssession                                        ERROR           8.74s   killed by signal 6 SIGABRT
 32/658 qemu:qtest+qtest-aarch64 / qtest-aarch64/migration-test                   ERROR          92.96s   killed by signal 6 SIGABRT
 34/658 qemu:qtest+qtest-i386 / qtest-i386/migration-test                         ERROR          96.63s   killed by signal 6 SIGABRT
 37/658 qemu:qtest+qtest-x86_64 / qtest-x86_64/migration-test                     ERROR          104.25s   killed by signal 6 SIGABRT

Dan Berrange investigated and found the ABI change in GnuTLS causing
this, since GnuTLS headers export public interfaces using time_t.
Which in turn is caused by a change in gnulib enabling _TIME_BITS=64

This seems to have started in GnuTLS 3.8.0.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02  0:29   ` Demi Marie Obenour
@ 2023-03-02  9:04     ` Daniel P. Berrangé
  2023-03-02 10:28       ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Daniel P. Berrangé @ 2023-03-02  9:04 UTC (permalink / raw)
  To: Demi Marie Obenour
  Cc: Eric Blake, Sam James, Carlos O'Donell via Libc-alpha,
	autoconf, c-std-porting, Zack Weinberg, David Seifert,
	Gentoo Toolchain, Arsen Arsenović,
	Paul Eggert, rjones

On Wed, Mar 01, 2023 at 07:29:01PM -0500, Demi Marie Obenour wrote:
> On 3/1/23 17:38, Eric Blake wrote:
> > [replying to the original post, because I'm not sure where else in the
> > more recent activity on this thread would be more appropriate]
> > 
> > On Fri, Nov 11, 2022 at 08:38:18AM +0000, Sam James wrote:
> >> Hi all,
> >>
> >> In Gentoo, we've been planning out what we should do for time64 on glibc [0]
> >> and concluded that we need some support in glibc for a newer option. I'll outline
> >> why below.
> >>
> > ...
> >>
> >> Indeed, the gnulib version of change #2 is exactly how we ended up with
> >> wget/gnutls breaking [1]. I feel this shows that the only approach
> >> "supported" by glibc right now is untenable.
> > 
> >> [1] https://bugs.gentoo.org/828001
> > 
> > Now Fedora is also being hit by the gnutls ABI change due to time_t in
> > public interfaces being silently changed.  From an IRC conversation I
> > had with Dan Berrange and Rich Jones (I think Rich mean i686 below):
> > 
> > <danpb> rjones (IRC): oh wow, the certificates created on i696 are not quite right .....
> > <danpb>         Validity:
> > <danpb>                 Not Before: Sat Sep 05 00:23:57 UTC 2703
> > <danpb>                 Not After: Sun Sep 06 00:23:57 UTC 2703
> > <danpb> just a few years too early
> > <danpb> i think this is looking like a gnutls regression,   downgrading gnutls makes it work
> > ...
> > <danpb> rjones (IRC): hmm, i'm beginning to think gnutls has been miscompiled by gcc
> > <danpb> gnutls_x509_crt_get_activation_time inside the gnutls verification api returns garbage
> > <danpb> but the very same call done from a demo program returns the right answer
> > ...
> > <danpb> OMG, gnulib-- has silently changed gnutls to use 64-bit time_t
> > <danpb> ...which is an ABI incompatibility because gnutls has public APIs which have time_t parameters
> > <danpb> so apps talking to gnutls will expect 32-bit time_t, but gnutls is processing 64-bit time_t
> > <danpb> this is utterly insane
> 
> Time to do a mass rebuild and mass SONAME bump of everything shipped as 32-bits?

A mass rebuild won't fix the problem, because the fundamental issue
is that apps using GNUTLS don't set _TIME_BITS=64 while GNUTLS does
set that, so they have incompatible views of what size time_t is.


GLibC sensibly hid the 64-bit time_t behind _TIME_BITS=64, so that
applications/libraries didn't get a silent ABI change when updating
to newer GLibC.

GNULIB's year2038 module will check for this _TIME_BITS=64 support
and if present, enable it. That would have been OK on its own as apps
would still be opting in to use of GNULIB's year2038 module.


The problem with GNUTLS arises because the pre-existing GNULIB largefile
module appears to also have been changed to set _TIME_BITS=64. Thus when
an application using the largefile module updates GNULIB, they unwittingly
get this change to time_t which impacts their ABI compatibility if they
export any APIs using time_t, or call into any other non-GLibC libraries
that use time_t in their APIs.

The compounding factor is that the GNULIB largefile module is something
probably any application has been using for decades. IOW, an opt-in GLiBC
change to 64-bit time_t has effectively become an always on change to
64-bit time_t for apps/libs using GNULIB.

I can understand the good intentions of GNULIB in making this change to
largefile expecting it to benefit apps, but I think it has a rather
unfortunate / undesirable ripple effect which makes it a net downside.

GNULIB did provide a --disable-year2038 flag to configure, however,
expecting every existing end user who builds apps/libs to consistently
know about and use --disable-year2038 is not practical IMHO.

Ideally GNUTLS would not have exposed time_t (or any other variable
size type) in its public API, but that's the unfortunately historical
baggage they can't address without an API+ABI change.


It is possible to argue that the situation with _TIME_BITS=64 is no
different to that of _FILE_OFFSET_BITS=64 usage, and from a purely
technical view that is correct. Both affect the size of certain GLibC
typedefs, and so can impact ABI compatibility of libararies whose public
APIs use such typedefs.

The difference I think is that _FILE_OFFSET_BITS=64 is ancient history.
Apps and libraries have been using _FILE_OFFSET_BITS=64 for 15-20 years
already. So while there is a chance of inconsistent usage, and thus
ABI incompatibility, in practice this is a non-issue since everything
of consequence has long ago opted in to _FILE_OFFSET_BITS=64. Also when
that was being adopted, 32-bit platforms were still in widespread use,
so developers & users fairly easily identified & fixed problems.

Today 32-bit is on its way out, so introducing a new _TIME_BITS=64 and
getting everything converted to use is a huge challenge, compounded by
the fact that very few developers ever test or use 32-bit anymore.

IMHO if distros really want to deal with this, they need to be able to
force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.

Having apps/libs incrementally adopt _TIME_BITS=64 in isolation is going
to drip feed incompatibility problems over years, many of which will go
undetected and silently cause problems. Some of these incompatibilities
could ultimately turn out to cause security flaws, because correctly
interpreting time is security critical in certain areas of code like
certificate validation. 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02  9:04     ` Daniel P. Berrangé
@ 2023-03-02 10:28       ` Paul Eggert
  2023-03-02 10:38         ` Andreas Schwab
  2023-03-02 11:02         ` Richard W.M. Jones
  0 siblings, 2 replies; 75+ messages in thread
From: Paul Eggert @ 2023-03-02 10:28 UTC (permalink / raw)
  To: Daniel P. Berrangé, Demi Marie Obenour
  Cc: Eric Blake, Sam James, Carlos O'Donell via Libc-alpha,
	autoconf, c-std-porting, Zack Weinberg, David Seifert,
	Gentoo Toolchain, Arsen Arsenović,
	rjones

On 2023-03-02 01:04, Daniel P. Berrangé wrote:
> IMHO if distros really want to deal with this, they need to be able to
> force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.

As things stand this is probably the best way to go. Although some pain 
is inevitable, this approach appears to be the least painful.

Mainstream developers long ago migrated to 64-bit time_t, and fewer and 
fewer of them have the time to worry about the shrinking subset of the 
embedded system world where legacy 32-bit time_t is still OK (at least 
for the next several months). It's incumbent on system builders who 
still cater to legacy 32-bit time_t (for now) to figure out how to 
wrangle their systems into the 64-bit time_t world; they can't really 
expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make the job much easier 
than it already is.


> So while there is a chance of inconsistent usage [with off_t], and thus
> ABI incompatibility, in practice this is a non-issue since everything
> of consequence has long ago opted in to _FILE_OFFSET_BITS=64.

Fifteen years from now we'll be saying the same thing about _TIME_BITS. 
There will be some pain in the meantime, just as there was with the 
_FILE_OFFSET_BITS transition, something I lived through and was not too 
happy about either.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 10:28       ` Paul Eggert
@ 2023-03-02 10:38         ` Andreas Schwab
  2023-03-03  5:46           ` Paul Eggert
  2023-03-02 11:02         ` Richard W.M. Jones
  1 sibling, 1 reply; 75+ messages in thread
From: Andreas Schwab @ 2023-03-02 10:38 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	rjones

On Mär 02 2023, Paul Eggert wrote:

> Fifteen years from now we'll be saying the same thing about
> _TIME_BITS. There will be some pain in the meantime, just as there was
> with the _FILE_OFFSET_BITS transition, something I lived through and was
> not too happy about either.

There is a huge difference between them: time_t has a flag day, off_t
doesn't.  You can still run with 32-bit off_t today and have everything
working.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 10:28       ` Paul Eggert
  2023-03-02 10:38         ` Andreas Schwab
@ 2023-03-02 11:02         ` Richard W.M. Jones
  2023-03-02 12:17           ` Bruno Haible
  2023-03-03 11:49           ` Florian Weimer
  1 sibling, 2 replies; 75+ messages in thread
From: Richard W.M. Jones @ 2023-03-02 11:02 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote:
> On 2023-03-02 01:04, Daniel P. Berrangé wrote:
> >IMHO if distros really want to deal with this, they need to be able to
> >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.
> 
> As things stand this is probably the best way to go. Although some
> pain is inevitable, this approach appears to be the least painful.

I think the question remains how to do this.  In Fedora we have a
concept of global C/C++ flags which most C/C++ applications obey:

$ rpm --eval '%{__global_cflags}'
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.
We didn't historically do this for -D_FILE_OFFSET_BITS, instead
relying on every application to switch for itself.

As Dan says, back then everyone was using 32 bit machines routinely.
Now (in Fedora at least) this breakage in a core package on i686 has
barely been noticed.

Another way to look at this is that it's a bug in gnutls and we should
fix it only in this package (and in future other packages that expose
time_t directly through public ABIs).  Would probably require at least
some symbol version trickery.

Another factor here is that Fedora is in the process of dropping i686,
the last remaining 32 bit platform since we dropped armv7 a few
releases ago.  So maybe this is not a problem for Fedora.

Rich.

> Mainstream developers long ago migrated to 64-bit time_t, and fewer
> and fewer of them have the time to worry about the shrinking subset
> of the embedded system world where legacy 32-bit time_t is still OK
> (at least for the next several months). It's incumbent on system
> builders who still cater to legacy 32-bit time_t (for now) to figure
> out how to wrangle their systems into the 64-bit time_t world; they
> can't really expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make
> the job much easier than it already is.
> 
> 
> >So while there is a chance of inconsistent usage [with off_t], and thus
> >ABI incompatibility, in practice this is a non-issue since everything
> >of consequence has long ago opted in to _FILE_OFFSET_BITS=64.
> 
> Fifteen years from now we'll be saying the same thing about
> _TIME_BITS. There will be some pain in the meantime, just as there
> was with the _FILE_OFFSET_BITS transition, something I lived through
> and was not too happy about either.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 11:02         ` Richard W.M. Jones
@ 2023-03-02 12:17           ` Bruno Haible
  2023-03-02 13:24             ` Daniel P. Berrangé
  2023-03-03 23:21             ` Arsen Arsenović
  2023-03-03 11:49           ` Florian Weimer
  1 sibling, 2 replies; 75+ messages in thread
From: Bruno Haible @ 2023-03-02 12:17 UTC (permalink / raw)
  To: Paul Eggert, Richard W.M. Jones
  Cc: Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

Richard W.M. Jones wrote:
> Another way to look at this is that it's a bug in gnutls and we should
> fix it only in this package

It's by far not just this one package. An 'fgrep -rl time_t /usr/include'
search shows a number of libraries that use time_t in their API:
  alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl,
  readline, libuuid, wxwidgets, X11, libxcb
- and that's just the few that I happen to have installed.

If a distro takes a package-by-package approach:
  - Some of these packages use Gnulib, and are thus causing trouble now or
    will soon.
  - The other packages (and there are a number of them!) will either
    require a manual switch to _TIME_BITS=64 or blow up in 2038.

I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass
rebuild is
  - more efficient than a package-by-package approach,
  - also less likely to leave out some packages by mistake.

> In Fedora we have a
> concept of global C/C++ flags which most C/C++ applications obey:
>
> $ rpm --eval '%{__global_cflags}'
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>
> We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.

How do you detect if a package (by mistake or intentionally) does
'#undef _TIME_BITS'?

A safer solution might be to hack the compilers (gcc and clang), so that
they make _TIME_BITS evaluate to 64, regardless of any '#define _TIME_BITS 32'
or '#undef _TIME_BITS' in the package's source code.

Bruno




^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 12:17           ` Bruno Haible
@ 2023-03-02 13:24             ` Daniel P. Berrangé
  2023-03-03  3:30               ` Wookey
  2023-03-03 23:21             ` Arsen Arsenović
  1 sibling, 1 reply; 75+ messages in thread
From: Daniel P. Berrangé @ 2023-03-02 13:24 UTC (permalink / raw)
  To: Bruno Haible
  Cc: Paul Eggert, Richard W.M. Jones, Demi Marie Obenour, Eric Blake,
	Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

On Thu, Mar 02, 2023 at 01:17:33PM +0100, Bruno Haible wrote:
> Richard W.M. Jones wrote:
> > Another way to look at this is that it's a bug in gnutls and we should
> > fix it only in this package
> 
> It's by far not just this one package. An 'fgrep -rl time_t /usr/include'
> search shows a number of libraries that use time_t in their API:
>   alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl,
>   readline, libuuid, wxwidgets, X11, libxcb
> - and that's just the few that I happen to have installed.
> 
> If a distro takes a package-by-package approach:
>   - Some of these packages use Gnulib, and are thus causing trouble now or
>     will soon.
>   - The other packages (and there are a number of them!) will either
>     require a manual switch to _TIME_BITS=64 or blow up in 2038.

To be clear, Fedora does not want to take a package-by-package
approach at all. It is getting imposed when we pick up new software
releases that happen to enable _TIME_BITS=64, either intentionally
or unwittingly.

> I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass
> rebuild is
>   - more efficient than a package-by-package approach,
>   - also less likely to leave out some packages by mistake.

On the Fedora side, the i686 support is very much of declining
relevance. Fedora approved the removal of "leaf" node packages
aka applications[1]. The remaining focus is primarily around
libraries so that 32-bit libs can be used on a 64-bit OS install
to support running 32-bit application binaries obtained from
external sources (primarily wine + steam related).

Those 32-bit binaries being targeted are going to be exclusively
using 32-bit time_t. IOW, doing a mass rebuild of the distro with
_TIME_BITS=64 will break compatibility with the very apps that
motivate the continued existance of i686 as a build target.

Thus from the Fedora POV the only viables paths I see are either
keeping with 32-bit time_t, or dropping i686 entirely. I would
expect Fedora to fully drop i686 before 2038 arrives anyway.

Other distros may have different priorities and find a mass
rebuild to enable 64-bit time_t interesting for their needs.
Most especially if their world is self-contained and thus
does not need to worry about compatibility with externally
distributed 32-bit binaries using 32-bit time_t.

Essentially i686 with 64-bit time_t needs to be considered
an entirely new build target. Either distros want to support
to this new target as a whole, or they want to stick with
the old target.

With regards,
Daniel

[1] https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 13:24             ` Daniel P. Berrangé
@ 2023-03-03  3:30               ` Wookey
  2023-03-03  5:50                 ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Wookey @ 2023-03-03  3:30 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Bruno Haible, Paul Eggert, Richard W.M. Jones,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

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

On 2023-03-02 13:24 +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 02, 2023 at 01:17:33PM +0100, Bruno Haible wrote:
> > Richard W.M. Jones wrote:
> > > Another way to look at this is that it's a bug in gnutls and we should
> > > fix it only in this package
> > 
> > It's by far not just this one package. An 'fgrep -rl time_t /usr/include'
> > search shows a number of libraries that use time_t in their API:
> >   alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl,
> >   readline, libuuid, wxwidgets, X11, libxcb
> > - and that's just the few that I happen to have installed.
> > 
> > If a distro takes a package-by-package approach:
> >   - Some of these packages use Gnulib, and are thus causing trouble now or
> >     will soon.
> >   - The other packages (and there are a number of them!) will either
> >     require a manual switch to _TIME_BITS=64 or blow up in 2038.

There are lots. I'm nearly 6000 packages into a 10,325 *-dev package
analysis in debian and have so far found 218 packages where enabling
_TIME_BITS=64 changes the ABI. (and 39 where enabling LFS changes the
ABI - implying that they are not being built with it now). 1068 didn't
change, (and 3713 don't actually contain a lib or headers - like 2000
golang* packages, and 895 need further analysis - many because the
libs and headers are not in the same package). So there could be
around 500 packages affected. (It was about 130 in Ubuntu main)

Gnulib automatically changing the ABI for packages that use it is
deeply unhelpful and is going to cause significant breakage and
hassle. I'd better start checking how many libraries in debian have
had their ABI incompatibly-changed already. Just because most users
are on 64-bit systems is no excuse for randomly breaking the 32-bit
ones.

We do need to make this transition in 32-bit world, but it also needs
to be done in an orderly fashion like any other ABI-breaking
transition - with SONAME changes and ordered uploads (or decide it's
too big, not do that, and start a new triplet/architecture). Neither
of these involves randomly changing the ABI on some libraries just
because they updated their gnulib.

I gave a FOSDEM talk on the state of play about a month ago on this
general issue in case anyone
cares:https://fosdem.org/2023/schedule/event/fixing_2038/

> Those 32-bit binaries being targeted are going to be exclusively
> using 32-bit time_t. IOW, doing a mass rebuild of the distro with
> _TIME_BITS=64 will break compatibility with the very apps that
> motivate the continued existance of i686 as a build target.

Right.

> Essentially i686 with 64-bit time_t needs to be considered
> an entirely new build target. Either distros want to support
> to this new target as a whole, or they want to stick with
> the old target.

Which is essentially x32, that has existed for some years (but has had
little adoption).  Debian builds it as an unoffical (i.e 'best
effort') port.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 10:38         ` Andreas Schwab
@ 2023-03-03  5:46           ` Paul Eggert
  2023-03-06  8:58             ` Andreas Schwab
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2023-03-03  5:46 UTC (permalink / raw)
  To: Andreas Schwab
  Cc: Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	rjones

On 3/2/23 02:38, Andreas Schwab wrote:
> There is a huge difference between them: time_t has a flag day, off_t
> doesn't.

Absolutely right.

Another thing that's different is that when off_t grew in the 1990s, 
people said they needed a wider off_t RIGHT NOW, because programs 
wouldn't work on large inputs otherwise. The pressure to build with 
_FILE_OFFSET_BITS=64 was large enough that a working consensus was 
reached pretty quickly to build that way.

In contrast, people don't urgently need a wider time_t until 2038. So 
the "let's be organized about this and do things systematically" 
sentiment wins, and because other things take priority time_t conversion 
never gets done. (Or possibly the "either the platform or I will be dead 
by 2038 so let's do nothing" sentiment wins, which is another 
seemingly-good reason to do nothing....)

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-03  3:30               ` Wookey
@ 2023-03-03  5:50                 ` Paul Eggert
  2023-03-03 14:01                   ` Wookey
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2023-03-03  5:50 UTC (permalink / raw)
  To: Wookey, Daniel P. Berrangé
  Cc: Bruno Haible, Richard W.M. Jones, Demi Marie Obenour, Eric Blake,
	Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

On 3/2/23 19:30, Wookey wrote:
> Gnulib automatically changing the ABI for packages that use it is
> deeply unhelpful and is going to cause significant breakage and
> hassle.

This change to Gnulib was reverted in December[1] and that propagated 
into bleeding-edge GnuTLS last month[2]. So if I understand things 
correctly the next GnuTLS release will go back to the old way of doing 
things, which will tempt the 32-bit time_t rearguard to fall back into 
"Let's not worry about 2038" mode.

However this is just one package. We'll likely see similar issues with 
other packages, independently of whether they use Gnulib, and 
independently of whether the built packages are not supposed to be used 
after the year 2038.

So this incident is a warning siren for the 32-bit time_t community. 
It's no time to relax.

[1]: 
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c
[2]: 
https://gitlab.com/gnutls/gnutls/-/commit/9622d7201e1d73d217c18802e1d435ba3404adb3


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 11:02         ` Richard W.M. Jones
  2023-03-02 12:17           ` Bruno Haible
@ 2023-03-03 11:49           ` Florian Weimer
  2023-03-03 12:39             ` Richard W.M. Jones
  1 sibling, 1 reply; 75+ messages in thread
From: Florian Weimer @ 2023-03-03 11:49 UTC (permalink / raw)
  To: Richard W.M. Jones via Libc-alpha
  Cc: Paul Eggert, Richard W.M. Jones, Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

* Richard W. M. Jones via Libc-alpha:

> On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote:
>> On 2023-03-02 01:04, Daniel P. Berrangé wrote:
>> >IMHO if distros really want to deal with this, they need to be able to
>> >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.
>> 
>> As things stand this is probably the best way to go. Although some
>> pain is inevitable, this approach appears to be the least painful.
>
> I think the question remains how to do this.  In Fedora we have a
> concept of global C/C++ flags which most C/C++ applications obey:
>
> $ rpm --eval '%{__global_cflags}'
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
>
> We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.
> We didn't historically do this for -D_FILE_OFFSET_BITS, instead
> relying on every application to switch for itself.

That still needs some per-package work (mainly for scripting languages
using FFI) because dlsym for gettimeofday etc. still find the 32-bit
variant.  There are various ways we can hack around that, I guess.

Anyway, this dual ABI break (for off_t and time_t) needs to be proposed
as a Fedora change, and we can discuss mechanics if Fedora wants to move
in that direction.  I think this is far from a given because a
still-unknown amount of third-party software will break.  GNUTLS, for
example, used to have a fairly stable ABI: libgnutls.so.30 goes back a
couple of years; I think it was part of CentOS 7 already.

I think the first step is to decide if we want to do this.  After that,
we can discuss mechanics.  For example, traditionally, ABI changes like
this have not been implemented through build flags injection in Fedora,
rather we updated the toolchain defaults.

Needless to say, I have very little interest to work on this (I consider
all this a pointless distraction, to be blunt), but I guess I can help
with toolchain enablement.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-03 11:49           ` Florian Weimer
@ 2023-03-03 12:39             ` Richard W.M. Jones
  0 siblings, 0 replies; 75+ messages in thread
From: Richard W.M. Jones @ 2023-03-03 12:39 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Richard W.M. Jones via Libc-alpha, Paul Eggert,
	Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

On Fri, Mar 03, 2023 at 12:49:04PM +0100, Florian Weimer wrote:
> * Richard W. M. Jones via Libc-alpha:
> 
> > On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote:
> >> On 2023-03-02 01:04, Daniel P. Berrangé wrote:
> >> >IMHO if distros really want to deal with this, they need to be able to
> >> >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.
> >> 
> >> As things stand this is probably the best way to go. Although some
> >> pain is inevitable, this approach appears to be the least painful.
> >
> > I think the question remains how to do this.  In Fedora we have a
> > concept of global C/C++ flags which most C/C++ applications obey:
> >
> > $ rpm --eval '%{__global_cflags}'
> > -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> >
> > We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.
> > We didn't historically do this for -D_FILE_OFFSET_BITS, instead
> > relying on every application to switch for itself.
> 
> That still needs some per-package work (mainly for scripting languages
> using FFI) because dlsym for gettimeofday etc. still find the 32-bit
> variant.  There are various ways we can hack around that, I guess.
> 
> Anyway, this dual ABI break (for off_t and time_t) needs to be proposed
> as a Fedora change, and we can discuss mechanics if Fedora wants to move
> in that direction.  I think this is far from a given because a
> still-unknown amount of third-party software will break.  GNUTLS, for
> example, used to have a fairly stable ABI: libgnutls.so.30 goes back a
> couple of years; I think it was part of CentOS 7 already.
> 
> I think the first step is to decide if we want to do this.  After that,
> we can discuss mechanics.  For example, traditionally, ABI changes like
> this have not been implemented through build flags injection in Fedora,
> rather we updated the toolchain defaults.
> 
> Needless to say, I have very little interest to work on this (I consider
> all this a pointless distraction, to be blunt), but I guess I can help
> with toolchain enablement.

To be clear, I wasn't suggesting we should do this, merely that it's a
thing that could be done :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-03  5:50                 ` Paul Eggert
@ 2023-03-03 14:01                   ` Wookey
  2023-03-03 14:14                     ` Daniel P. Berrangé
  0 siblings, 1 reply; 75+ messages in thread
From: Wookey @ 2023-03-03 14:01 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Bruno Haible, Richard W.M. Jones, Demi Marie Obenour, Eric Blake,
	Sam James, Carlos O'Donell via Libc-alpha, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović, dueno, Daniel P. Berrangé

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

On 2023-03-02 21:50 -0800, Paul Eggert wrote:
> On 3/2/23 19:30, Wookey wrote:

> > Gnulib automatically changing the ABI for packages that use it
> > (and have LFS already enabled) is deeply unhelpful...

> This change to Gnulib was reverted in December[1] and that propagated into
> bleeding-edge GnuTLS last month[2]. So if I understand things correctly the
> next GnuTLS release will go back to the old way of doing things,

OK. gnulib doesn't seem to have releases as such (last release v0.1 9
years ago), and is normally used embedded in the upstream source like
autotools (right?). What is a good test for whether a package/upstream
is affected by this 'gnulib might have turned 64-bit time' issue? Is
there an embedded gnulib version one can check, or does one have to look
at dates of the m4/year2038.m4 and m4/largefile.m4 files in the source?

I've not properly analysed this yet but presumably the problem arises if you have
m4/largefile.m4 and m4/year2038.m4 from between 2012-07-02 and 2022-12-25.
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/largefile.m4;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/year2038.m4;h=2e4427e6fac10550c99748abebf31b61e6afda2b;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa

https://git.savannah.gnu.org/cgit/gnulib.git/log/m4/largefile.m4?h=stable-202301

> which will tempt the 32-bit time_t rearguard to fall back into
> "Let's not worry about 2038" mode.

Up to a point. I think enough people are taking notice now that those
who care will be getting at least the core of this transition done
this year. (Althought there will always be ancient bits of
unmaintained software that don't get fixed until it actually breaks in
2038).

> However this is just one package. We'll likely see similar issues with other
> packages, independently of whether they use Gnulib, and independently of
> whether the built packages are not supposed to be used after the year 2038.

Yep. I noticed tar changing in debian (which may not involve any
changing external interfaces so is hopefully OK, but I'm not sure the
maintainers really understood what they should be checking before flicking
the switch)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204
This will be the normal case (upstream see a test failure and just enable
the thing that makes the test work without necessarily understanding that
they are/might-be part of a chain of ABI changes).

> So this incident is a warning siren for the 32-bit time_t community. It's no
> time to relax.
> 
> [1]: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c
> [2]: https://gitlab.com/gnutls/gnutls/-/commit/9622d7201e1d73d217c18802e1d435ba3404adb3

I made this wiki page for Debian's transition (which still needs a
proper community discussion to agree a plan - I'm currently trying to
collect the info needed for that discussion to be productive):
https://wiki.debian.org/ReleaseGoals/64bit-time

I will update it with this gnulib info once I understand it properly.

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-03 14:01                   ` Wookey
@ 2023-03-03 14:14                     ` Daniel P. Berrangé
  0 siblings, 0 replies; 75+ messages in thread
From: Daniel P. Berrangé @ 2023-03-03 14:14 UTC (permalink / raw)
  To: Wookey
  Cc: Paul Eggert, Bruno Haible, Richard W.M. Jones,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	dueno

On Fri, Mar 03, 2023 at 02:01:35PM +0000, Wookey wrote:
> On 2023-03-02 21:50 -0800, Paul Eggert wrote:
> > On 3/2/23 19:30, Wookey wrote:
> 
> > > Gnulib automatically changing the ABI for packages that use it
> > > (and have LFS already enabled) is deeply unhelpful...
> 
> > This change to Gnulib was reverted in December[1] and that propagated into
> > bleeding-edge GnuTLS last month[2]. So if I understand things correctly the
> > next GnuTLS release will go back to the old way of doing things,
> 
> OK. gnulib doesn't seem to have releases as such (last release v0.1 9
> years ago), and is normally used embedded in the upstream source like
> autotools (right?). What is a good test for whether a package/upstream
> is affected by this 'gnulib might have turned 64-bit time' issue? Is
> there an embedded gnulib version one can check, or does one have to look
> at dates of the m4/year2038.m4 and m4/largefile.m4 files in the source?

Looks like you can probably detect it from the configure --help
output. Based on this commit:

> > [1]: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c

The original problematic impl has this:

- AC_ARG_ENABLE([year2038],
-   [  --disable-year2038      omit support for timestamps past the year 2038])

the new code which does not enable 2038 by default has

+[AC_ARG_ENABLE([year2038],
+  m4_provide_if([AC_SYS_YEAR2038],
+    [AS_HELP_STRING([--disable-year2038],
+      [do not support timestamps after 2038])],
+    [AS_HELP_STRING([--enable-year2038],
+      [support timestamps after 2038])]))])

So if

  configure --help | grep disable-year2038

says 'omit support for timestamps past the year 2038', the app is
suspect and might face ABI compat issues.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-02 12:17           ` Bruno Haible
  2023-03-02 13:24             ` Daniel P. Berrangé
@ 2023-03-03 23:21             ` Arsen Arsenović
  1 sibling, 0 replies; 75+ messages in thread
From: Arsen Arsenović @ 2023-03-03 23:21 UTC (permalink / raw)
  To: Bruno Haible
  Cc: Paul Eggert, Richard W.M. Jones, Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain, dueno,
	distributions

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

Evening all,

[CC += distributions@lists.linux.dev as a thread about this popped up
 there]

Before anything else, I'd like to say that I'd prefer no distributor
acts on this issue until a smooth (or, at least, common) solution can be
established.

Bruno Haible <bruno@clisp.org> writes:

> Richard W.M. Jones wrote:
>> Another way to look at this is that it's a bug in gnutls and we should
>> fix it only in this package
>
> It's by far not just this one package. An 'fgrep -rl time_t /usr/include'
> search shows a number of libraries that use time_t in their API:
>   alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl,
>   readline, libuuid, wxwidgets, X11, libxcb
> - and that's just the few that I happen to have installed.
>
> If a distro takes a package-by-package approach:
>   - Some of these packages use Gnulib, and are thus causing trouble now or
>     will soon.
>   - The other packages (and there are a number of them!) will either
>     require a manual switch to _TIME_BITS=64 or blow up in 2038.
>
> I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass
> rebuild is
>   - more efficient than a package-by-package approach,
>   - also less likely to leave out some packages by mistake.

While I do too, and I believe this is the path forward for supporting
people with 32 bit hardware in y>=2038, this is *still* an ABI break,
and there is a regrettably large amount of proprietary software in the
world that users would expect to work (think games et al) which directly
depends on this ABI.  It is not as trivial as it may seem at first.  On
top of that, this still keeps the FFI problems Florian was talking
about.

I see two possibly slightly overlapping camps here:

1) AMD64 -m32 multilib users, who need this ABI for old, crusty non-Free
   binaries,
2) People running 32-bit hardware

(plus one that complains about 64 bit types consuming more memory which
I choose to ignore)

Supporting these both is a conflicting goal, (1) requires that time
remains 32 bit, and (2) does not care about that at all, and would
prefer a flag day which lets them have systems they can smoothly
continue to operate in fifteen years.  This is why I don't think
shoehorning _TIME_BITS=64 will work.

I (in personal capacity) think our best shot at supporting all of these
cases is to not opportunistically use _TIME_BITS (as it's difficult to
detect whether the rest of the system was built the same way), and
provide a hard break flag on glibc, with, potentially, a new
multilib/whathaveyou.

Let's establish a convention now, and just call the 64-bit time_t (et
al) gnuy39.  We can then use existing multilib practice we all have to
eventually migrate our i?86 systems to i?86-*-gnuy39 with an i?86-*-gnu
multilib for those that need it.  I imagine amd64 users won't ever need
i?86-*-gnuy39, but, in theory, this maps to that scenario, too.

Keep in mind, also, that we need to form a consensus on this.  Vendors
that produce the kind of software we're spending effort providing
compatibility for will just pick one or two distros to target, and so,
it's crucial that other distros follow the same conventions (including
source-based ones, because source-based needn't imply *fully* built from
source - we often need compatibility with software built for RHEL/Deb).

Enabling this requires the previously suggested ability to shift
"primary" symbols like gettimeofday to time64, rather than segregating
them to _TIME_BITS=64.  What I was thinking of above is having that be a
new $os value.  This should be easy to match.

>> In Fedora we have a
>> concept of global C/C++ flags which most C/C++ applications obey:
>>
>> $ rpm --eval '%{__global_cflags}'
>> -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
>> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
>> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
>> -fcf-protection
>>
>> We could stick -D_TIME_BITS=64 in there and then do a mass rebuild.
>
> How do you detect if a package (by mistake or intentionally) does
> '#undef _TIME_BITS'?
>
> A safer solution might be to hack the compilers (gcc and clang), so that
> they make _TIME_BITS evaluate to 64, regardless of any '#define _TIME_BITS 32'
> or '#undef _TIME_BITS' in the package's source code.

I'm not a huge fan of hacking cpp to do this, packagers could easily
check for this automatically, which is already a lot of "free"
"automated" testing.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-03  5:46           ` Paul Eggert
@ 2023-03-06  8:58             ` Andreas Schwab
  2023-03-06 10:19               ` Florian Weimer
  0 siblings, 1 reply; 75+ messages in thread
From: Andreas Schwab @ 2023-03-06  8:58 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James,
	Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
	Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	rjones

On Mär 02 2023, Paul Eggert wrote:

> Another thing that's different is that when off_t grew in the 1990s,
> people said they needed a wider off_t RIGHT NOW, because programs wouldn't
> work on large inputs otherwise.

That is only true for rather few selected programs.

> The pressure to build with _FILE_OFFSET_BITS=64 was large enough that
> a working consensus was reached pretty quickly to build that way.

The pressure for 64-bit time_t is much higher, because it affects almost
every program.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: On time64 and Large File Support
  2023-03-06  8:58             ` Andreas Schwab
@ 2023-03-06 10:19               ` Florian Weimer
  0 siblings, 0 replies; 75+ messages in thread
From: Florian Weimer @ 2023-03-06 10:19 UTC (permalink / raw)
  To: Andreas Schwab via Libc-alpha
  Cc: Paul Eggert, Andreas Schwab, Daniel P. Berrangé,
	Demi Marie Obenour, Eric Blake, Sam James, autoconf,
	c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
	Arsen Arsenović,
	rjones

* Andreas Schwab via Libc-alpha:

> On Mär 02 2023, Paul Eggert wrote:
>
>> Another thing that's different is that when off_t grew in the 1990s,
>> people said they needed a wider off_t RIGHT NOW, because programs wouldn't
>> work on large inputs otherwise.
>
> That is only true for rather few selected programs.

It depends on the system configuration.  For some file systems, inode
numbers outside the 32-bit range can be quite common.  This impacts
32-bit applications even if they never use ino_t because functions such
as fstat and readdir cannot know that these fields are unused.

We've been working around this for our 32-bit builders with special file
system configuration because like many, we do not build everything with
-D_FILE_OFFSET_BITS=64.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-02-27  2:30                                           ` time for Autoconf 2.72 (was: On time64 and Large File Support) Sam James
@ 2023-03-17 23:47                                             ` Sam James
  2023-03-18  0:59                                               ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Sam James @ 2023-03-17 23:47 UTC (permalink / raw)
  To: Frederic Berat, Paul Eggert, Zack Weinberg
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

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


Sam James <sam@gentoo.org> writes:

> [[PGP Signed Part:Undecided]]
>
>
>> On 3 Feb 2023, at 07:43, Frederic Berat <fberat@redhat.com> wrote:
>> 
>> Hi,
>> 
>> I'm also in favor of an RC release, I can then rebuild Fedora packages using the tarball from the tester list and do some kind of A/B testing.
>> 
> Paul, would you be willing to try this? I don't think much work should be needed (famous last words) other than the tag & uploading it,
> given the target audience  - that is, I wouldn't worry over testing it extensively given that's the point of the RC for now, and that can always be done
> before a subsequent RC or final release.
>
> Autoconf is currently one of the big barriers to making more progress on the C porting front, unfortunately and trying to explain
> to upstreams that some issues are ok-but-will-be-fixed-later ends up being confusing.
>
> If you're not able to look into an RC, I can try ship a snapshot in Gentoo which won't be generally available to users, but
> ask for eager users to test, but that won't help with other distros or interested parties.
>
> I'm happy to do the work if someone can tell me what needs doing, as well.
>
> I'm sorry to ask directly, it's just that it keeps coming up in discussions with upstreams & package maintainers.

Clang 16 was released today. Unfortunately, all released versions of
autoconf still generate configure scripts which are incompatible with it.

Is anyone aware of any issues with master as it is? I've been running
with it for months.

>
> Best,
> sam
>
> [[End of PGP Signed Part]]


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-03-17 23:47                                             ` Sam James
@ 2023-03-18  0:59                                               ` Paul Eggert
  2023-03-18  2:08                                                 ` Jim Meyering
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2023-03-18  0:59 UTC (permalink / raw)
  To: Sam James, Frederic Berat, Zack Weinberg
  Cc: Florian Weimer, Wookey, autoconf-patches, c-std-porting

On 3/17/23 16:47, Sam James wrote:
> Clang 16 was released today. Unfortunately, all released versions of
> autoconf still generate configure scripts which are incompatible with it.

Presumably "./configure CC='clang -std=gnu17" is a workaround, though 
admittedly this is awkward.

> Is anyone aware of any issues with master as it is? I've been running
> with it for months.

Thanks for the info. I've been too swamped to shepherd a release, 
unfortunately. But we should do one soon.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-03-18  0:59                                               ` Paul Eggert
@ 2023-03-18  2:08                                                 ` Jim Meyering
  2023-03-18  2:52                                                   ` Paul Eggert
  0 siblings, 1 reply; 75+ messages in thread
From: Jim Meyering @ 2023-03-18  2:08 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Sam James, Frederic Berat, Zack Weinberg, Florian Weimer, Wookey,
	autoconf-patches, c-std-porting

On Fri, Mar 17, 2023 at 6:00 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 3/17/23 16:47, Sam James wrote:
> > Clang 16 was released today. Unfortunately, all released versions of
> > autoconf still generate configure scripts which are incompatible with it.
>
> Presumably "./configure CC='clang -std=gnu17" is a workaround, though
> admittedly this is awkward.
>
> > Is anyone aware of any issues with master as it is? I've been running
> > with it for months.

I used master in releasing grep-3.9 recently, and that has so far
exposed no issue.

> Thanks for the info. I've been too swamped to shepherd a release,
> unfortunately. But we should do one soon.

There are a bunch of pending patches, for which I've been unable to find time.
Can someone see if there's some small/safe set of changes that are essential?
If none (or few/easy), I might have time to make a snapshot soon.

I wouldn't be averse to making a quick release now, and to plan for a
follow-up once people find time for additional patches.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-03-18  2:08                                                 ` Jim Meyering
@ 2023-03-18  2:52                                                   ` Paul Eggert
  2023-03-19  0:30                                                     ` Jim Meyering
  0 siblings, 1 reply; 75+ messages in thread
From: Paul Eggert @ 2023-03-18  2:52 UTC (permalink / raw)
  To: Jim Meyering
  Cc: Sam James, Frederic Berat, Zack Weinberg, Florian Weimer, Wookey,
	autoconf-patches, c-std-porting

On 3/17/23 19:08, Jim Meyering wrote:
> Can someone see if there's some small/safe set of changes that are essential?
> If none (or few/easy), I might have time to make a snapshot soon.

As far as I know, none of the pending patches are essential and we can 
release what we have.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-03-18  2:52                                                   ` Paul Eggert
@ 2023-03-19  0:30                                                     ` Jim Meyering
  2023-03-19  0:57                                                       ` Sam James
  0 siblings, 1 reply; 75+ messages in thread
From: Jim Meyering @ 2023-03-19  0:30 UTC (permalink / raw)
  To: Paul Eggert
  Cc: Sam James, Frederic Berat, Zack Weinberg, Florian Weimer, Wookey,
	autoconf-patches, c-std-porting

On Fri, Mar 17, 2023 at 7:52 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 3/17/23 19:08, Jim Meyering wrote:
> > Can someone see if there's some small/safe set of changes that are essential?
> > If none (or few/easy), I might have time to make a snapshot soon.
>
> As far as I know, none of the pending patches are essential and we can
> release what we have.

Good. Thanks. It just so happens that I'm about to make a snapshot of
grep (for this:
https://lists.gnu.org/r/bug-grep/2023-03/msg00005.html) using the very
latest autoconf, including many changes that were not used in making
grep-3.9 (I was surprised to realize 3.9 was bootstrapped with
something near v2.72a-65-gd081ac3e, from October(!)). Let's see how
grep snapshot testing goes, and if there's no objection by then, I'll
plan to make an autoconf snapshot within a week or so.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: time for Autoconf 2.72 (was: On time64 and Large File Support)
  2023-03-19  0:30                                                     ` Jim Meyering
@ 2023-03-19  0:57                                                       ` Sam James
  0 siblings, 0 replies; 75+ messages in thread
From: Sam James @ 2023-03-19  0:57 UTC (permalink / raw)
  To: Jim Meyering
  Cc: Paul Eggert, Frederic Berat, Zack Weinberg, Florian Weimer,
	Wookey, autoconf-patches, c-std-porting

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


Jim Meyering <jim@meyering.net> writes:

> On Fri, Mar 17, 2023 at 7:52 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>> On 3/17/23 19:08, Jim Meyering wrote:
>> > Can someone see if there's some small/safe set of changes that are essential?
>> > If none (or few/easy), I might have time to make a snapshot soon.
>>
>> As far as I know, none of the pending patches are essential and we can
>> release what we have.
>
> Good. Thanks. It just so happens that I'm about to make a snapshot of
> grep (for this:
> https://lists.gnu.org/r/bug-grep/2023-03/msg00005.html) using the very
> latest autoconf, including many changes that were not used in making
> grep-3.9 (I was surprised to realize 3.9 was bootstrapped with
> something near v2.72a-65-gd081ac3e, from October(!)). Let's see how
> grep snapshot testing goes, and if there's no objection by then, I'll
> plan to make an autoconf snapshot within a week or so.

Thanks Jim. Please give me a shout if I can assist. And I'll go test
the new grep snap.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 377 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

end of thread, other threads:[~2023-03-19  0:58 UTC | newest]

Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-11  8:38 On time64 and Large File Support Sam James
2022-11-11  9:16 ` Paul Eggert
2022-11-11  9:19   ` Sam James
2022-11-11 23:48   ` Joseph Myers
2022-11-11  9:19 ` Florian Weimer
2022-11-11  9:27   ` Sam James
2022-11-11 11:38     ` Florian Weimer
2022-11-11 20:12       ` Paul Eggert
2022-11-12  2:20     ` Zack Weinberg
2022-11-12  3:57       ` Sam James
2022-11-12 14:16         ` Zack Weinberg
2022-11-12 17:41           ` Paul Eggert
2022-11-12 18:50             ` Bruno Haible
2022-11-12 19:15               ` Paul Eggert
2022-11-12 20:23                 ` Wookey
2022-11-12 20:54                   ` Russ Allbery
2022-11-12 21:31                   ` Paul Eggert
     [not found]                     ` <951fc967-042c-4978-bd78-8bc4c8706b18@app.fastmail.com>
2022-11-13  5:11                       ` Zack Weinberg
2022-11-15  5:06                         ` Sam James
2022-12-25 19:19                         ` Paul Eggert
2022-12-29  4:02                           ` Zack Weinberg
2022-12-30 22:12                             ` Paul Eggert
2022-12-30 22:20                               ` Sam James
2023-01-20  9:56                               ` Paul Eggert
2023-02-02  6:43                                 ` Sam James
2023-02-02 23:15                                   ` time for Autoconf 2.72 (was: On time64 and Large File Support) Paul Eggert
2023-02-02 23:17                                     ` Zack Weinberg
2023-02-03  5:49                                       ` Sam James
2023-02-03 12:43                                         ` time for Autoconf 2.72 Bruno Haible
     [not found]                                         ` <CAObJKZp2CCRR46-X9NYaRES7eDCVyoJ0xv=u4aSG2KeQv4vtjA@mail.gmail.com>
2023-02-27  2:30                                           ` time for Autoconf 2.72 (was: On time64 and Large File Support) Sam James
2023-03-17 23:47                                             ` Sam James
2023-03-18  0:59                                               ` Paul Eggert
2023-03-18  2:08                                                 ` Jim Meyering
2023-03-18  2:52                                                   ` Paul Eggert
2023-03-19  0:30                                                     ` Jim Meyering
2023-03-19  0:57                                                       ` Sam James
2022-11-15  5:09                     ` On time64 and Large File Support Sam James
2022-11-12 18:19       ` Paul Eggert
2022-11-11  9:40   ` Andreas K. Huettel
2022-11-11 11:30     ` Florian Weimer
2022-11-11 19:01       ` Andreas K. Huettel
2022-11-11 19:28         ` Palmer Dabbelt
2022-11-11  9:46   ` Paul Eggert
2022-11-11 11:22     ` Florian Weimer
2022-11-11 19:56       ` Paul Eggert
2022-11-12  4:20   ` Wookey
2022-11-12  4:28     ` Sam James
2022-11-12  4:56       ` Wookey
2022-11-12  4:59         ` Sam James
2022-11-12 18:33     ` Paul Eggert
2022-11-14  8:39   ` Adam Sampson
2022-11-14 11:47     ` Florian Weimer
2022-11-14 20:26     ` Arsen Arsenović
2022-11-14 20:52       ` Florian Weimer
2022-11-15  7:39         ` Arsen Arsenović
2022-11-11 10:25 ` Richard Purdie
2023-03-01 22:38 ` Eric Blake
2023-03-02  0:29   ` Demi Marie Obenour
2023-03-02  9:04     ` Daniel P. Berrangé
2023-03-02 10:28       ` Paul Eggert
2023-03-02 10:38         ` Andreas Schwab
2023-03-03  5:46           ` Paul Eggert
2023-03-06  8:58             ` Andreas Schwab
2023-03-06 10:19               ` Florian Weimer
2023-03-02 11:02         ` Richard W.M. Jones
2023-03-02 12:17           ` Bruno Haible
2023-03-02 13:24             ` Daniel P. Berrangé
2023-03-03  3:30               ` Wookey
2023-03-03  5:50                 ` Paul Eggert
2023-03-03 14:01                   ` Wookey
2023-03-03 14:14                     ` Daniel P. Berrangé
2023-03-03 23:21             ` Arsen Arsenović
2023-03-03 11:49           ` Florian Weimer
2023-03-03 12:39             ` Richard W.M. Jones
2023-03-02  8:30   ` Richard W.M. Jones

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).