On time64 and Large File Support

On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Joseph Myers]

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

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Paul Eggert]

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

Re: On time64 and Large File Support

[Zack Weinberg]

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

Re: On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Zack Weinberg]

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

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Bruno Haible]

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

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Wookey]

[-- 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 --]

Re: On time64 and Large File Support

[Russ Allbery]

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

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Andreas K. Huettel]

[-- 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 --]

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Andreas K. Huettel]

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

Re: On time64 and Large File Support

[Palmer Dabbelt]

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

Re: On time64 and Large File Support

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


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

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Wookey]

[-- 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 --]

Re: On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Wookey]

[-- 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 --]

Re: On time64 and Large File Support

[Sam James]

[-- 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 --]

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Adam Sampson]

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

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Arsen Arsenović]

[-- 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 --]

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Arsen Arsenović]

[-- 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 --]

Re: On time64 and Large File Support

[Richard Purdie]

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

Re: On time64 and Large File Support

[Eric Blake]

[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

Re: On time64 and Large File Support

[Demi Marie Obenour]

[-- 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 --]

Re: On time64 and Large File Support

[Daniel P. Berrangé]

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

Re: On time64 and Large File Support

[Paul Eggert]

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.

Re: On time64 and Large File Support

[Andreas Schwab]

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

Re: On time64 and Large File Support

[Paul Eggert]

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

Re: On time64 and Large File Support

[Andreas Schwab]

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

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Richard W.M. Jones]

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

Re: On time64 and Large File Support

[Bruno Haible]

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

Re: On time64 and Large File Support

[Daniel P. Berrangé]

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

Re: On time64 and Large File Support

[Wookey]

[-- 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 --]

Re: On time64 and Large File Support

[Paul Eggert]

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

Re: On time64 and Large File Support

[Wookey]

[-- 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 --]

Re: On time64 and Large File Support

[Daniel P. Berrangé]

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

Re: On time64 and Large File Support

[Arsen Arsenović]

[-- 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 --]

Re: On time64 and Large File Support

[Florian Weimer]

* 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

Re: On time64 and Large File Support

[Richard W.M. Jones]

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

Re: On time64 and Large File Support

[Richard W.M. Jones]

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