* Re: On time64 and Large File Support
2022-11-11 9:19 ` Florian Weimer
@ 2022-11-11 9:27 ` Sam James
2022-11-11 11:38 ` Florian Weimer
2022-11-12 2:20 ` Zack Weinberg
2022-11-11 9:40 ` Andreas K. Huettel
` (3 subsequent siblings)
4 siblings, 2 replies; 56+ messages in thread
From: Sam James @ 2022-11-11 9:27 UTC (permalink / raw)
To: Florian Weimer
Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Paul Eggert, Frederic Berat, bug-gnulib
[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]
> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>
> * Sam James:
>
>> In Gentoo, we've been planning out what we should do for time64 on
>> glibc [0] and concluded that we need some support in glibc for a newer
>> option. I'll outline why below.
>>
>> Proposal: glibc gains two new build-time configure options:
>> * --enable-hard-time64
>> * --enable-hard-lfs
>
> We should define new target triplets for this if it's really required.
I hadn't considered that option. I'll reflect on it. Please let me know
if you have further thoughts on this.
But that said, these binaries are broken anyway in 2038?
> We need to support legacy binaries on i386. Few libraries are
> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
> to LFS or time64 needs to be evaluated on a per-library basis. For most
> distributions, no one is going to do that work, and we have to stick to
> whathever we are building today.
While I agree, I don't think it's as well-known that it should be that
these are ABI breaking and require inspection. It's being done ad-hoc
or in many cases, not at all.
Part of the use of this thread is, if nothing else, we can show upstreams
and other distros It if they're confused.
It's very easy to miss that a package has started enabling LFS
and then your opportunity to catch the ABI breakage is gone.
It doesn't help that I (and I suspect most distribution maintainers)
do all development on x86_64 and hence even ABI diffing isn't
going to notice. You have to specifically diff the build system, which I
do, but it's not easy if it's buried deep within gnulib or something.
>
>> These would hard-enable the relevant #defines within glibc's headers
>> and ensure that any binaries built with such a glibc have both Large
>> File Support (LFS) and time64 support.
>>
>> I've come to the conclusion it's infeasible to try handle the
>> migration piecemeal. Various mismatches can and will occur (and while
>> it's more likely with time64, it's possible with LFS too) [1].
>>
>> We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
>> of note [2][3]
>> 1. addition of a new AC_SYS_YEAR2038 macro;
>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>
>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>> wget/gnutls breaking [1]. I feel this shows that the only approach
>> "supported" by glibc right now is untenable.
>
> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
>
> I thought the gnulib change has been reverted?
>
> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions. If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port. Debian will probably be impacted in the same way.
>
Right, we need to be unified on this, because it's confusing enough
without unilateralism.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:27 ` Sam James
@ 2022-11-11 11:38 ` Florian Weimer
2022-11-11 20:12 ` Paul Eggert
2022-11-12 2:20 ` Zack Weinberg
1 sibling, 1 reply; 56+ messages in thread
From: Florian Weimer @ 2022-11-11 11:38 UTC (permalink / raw)
To: Sam James
Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Paul Eggert, Frederic Berat, bug-gnulib
* Sam James:
>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Sam James:
>>
>>> In Gentoo, we've been planning out what we should do for time64 on
>>> glibc [0] and concluded that we need some support in glibc for a newer
>>> option. I'll outline why below.
>>>
>>> Proposal: glibc gains two new build-time configure options:
>>> * --enable-hard-time64
>>> * --enable-hard-lfs
>>
>> We should define new target triplets for this if it's really required.
>
> I hadn't considered that option. I'll reflect on it. Please let me know
> if you have further thoughts on this.
>
> But that said, these binaries are broken anyway in 2038?
No, I expect users to run them in time-shifted VMs or containers.
Wrong dates are better than no ability to run anything at all.
And whoever can recompile to switch to time64 can just recompile for a
64-bit target. There are some embedded users that stick to 32-bit for
cost savings, but I think the cost allocation is quite wrong: They save
a bit on per-unit costs, but they do not really contribute back to GNU
(and most don't even use glibc, although there is some use out there).
>> We need to support legacy binaries on i386. Few libraries are
>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
>> to LFS or time64 needs to be evaluated on a per-library basis. For most
>> distributions, no one is going to do that work, and we have to stick to
>> whathever we are building today.
>
> While I agree, I don't think it's as well-known that it should be that
> these are ABI breaking and require inspection. It's being done ad-hoc
> or in many cases, not at all.
>
> Part of the use of this thread is, if nothing else, we can show upstreams
> and other distros It if they're confused.
>
> It's very easy to miss that a package has started enabling LFS
> and then your opportunity to catch the ABI breakage is gone.
>
> It doesn't help that I (and I suspect most distribution maintainers)
> do all development on x86_64 and hence even ABI diffing isn't
> going to notice. You have to specifically diff the build system, which I
> do, but it's not easy if it's buried deep within gnulib or something.
I really assumed that setting the default in glibc would solve this for
everyone: binary distributions keep using time32, and source-based
embedded distributions can switch to time64 if they want to. *sigh*
I mean, we have things like more compact stack usage through certain
ABI-breaking GCC options. The kernel can use those safely, but few
people attempt to apply them to userspace. There, having the right
default in the toolchain is sufficient. I didn't expect time64 to be
different.
Thanks,
Florian
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 11:38 ` Florian Weimer
@ 2022-11-11 20:12 ` Paul Eggert
0 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2022-11-11 20:12 UTC (permalink / raw)
To: Florian Weimer
Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Frederic Berat, bug-gnulib, Sam James
On 2022-11-11 03:38, Florian Weimer wrote:
>> But that said, these binaries are broken anyway in 2038?
> No, I expect users to run them in time-shifted VMs or containers.
That's reasonable for systems where accurate timestamps are not
important and where time_t width mismatches would just get in the way.
However, if this is the expected approach, I suggest having a standard
and well-documented way to timeshift VMs and containers, and unless you
want to cede the field entirely to other platforms this documentation
effort and testing should be done now rather than in the year 2037.
(Another thing to add to your bulging to-do list....)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:27 ` Sam James
2022-11-11 11:38 ` Florian Weimer
@ 2022-11-12 2:20 ` Zack Weinberg
2022-11-12 3:57 ` Sam James
2022-11-12 18:19 ` Paul Eggert
1 sibling, 2 replies; 56+ messages in thread
From: Zack Weinberg @ 2022-11-12 2:20 UTC (permalink / raw)
To: Sam James
Cc: Florian Weimer, Paul Eggert, libc-alpha, autoconf, c-std-porting,
toolchain, bug-gnulib
Sam James <sam@gentoo.org> writes:
>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>> We need to support legacy binaries on i386. Few libraries are
>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
>> to LFS or time64 needs to be evaluated on a per-library basis. For most
>> distributions, no one is going to do that work, and we have to stick to
>> whathever we are building today.
>
> While I agree, I don't think it's as well-known that it should be that
> these are ABI breaking and require inspection. It's being done ad-hoc
> or in many cases, not at all.
…
>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>> contains two changes of note [2][3]
>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>>
>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>> "supported" by glibc right now is untenable.
>>
>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>> for Fedora unfortunately.
>>
>> I thought the gnulib change has been reverted?
>>
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions.
There seems to be a disconnect between Paul Eggert’s position on these
changes and everyone else on this thread’s position.
I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
overriding the glibc maintainers. Rather, I think he was only thinking
about applications, not libraries, and only about source distribution.
If an application is being built on the machine where it’ll be used, and
both it and the system support building it with 64-bit time_t and off_t,
*why wouldn’t you*? It has no impact on anything else to do that, and
it future-proofs your installataion.
But everyone else is worrying about cases where, either, an application
is built with 64-bit time_t and/or off_t and then copied to a different
system where the underlying libraries *don’t* support that, or a *shared
library* is rebuilt with 64-bit time_t and/or off_t and that silently
changes its ABI out from under programs that use it.
(It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
difficult for any shared library other than glibc to offer *both* time_t
and time64_t binary interfaces.)
(It’s also unfortunate that, 20+ years after the invention of ELF symbol
versioning, it’s still ridiculously difficult. So many macros and
assembly hacks and fighting with libtool. But I digress.)
I am honestly not sure what to do about this in the long term, but for
the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038. That will
limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
added it, and should make it safe for Fedora and Gentoo to drop in 2.72
in order to unblock C23 testing — am I correct? It doesn’t resolve the
larger issue, but it gives us more time to think about what the
resolution ought to be.
What do you think?
zw
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 2:20 ` Zack Weinberg
@ 2022-11-12 3:57 ` Sam James
2022-11-12 14:16 ` Zack Weinberg
2022-11-12 18:19 ` Paul Eggert
1 sibling, 1 reply; 56+ messages in thread
From: Sam James @ 2022-11-12 3:57 UTC (permalink / raw)
To: Zack Weinberg
Cc: Florian Weimer, Paul Eggert, Carlos O'Donell via Libc-alpha,
autoconf, c-std-porting, toolchain, bug-gnulib
[-- Attachment #1: Type: text/plain, Size: 5176 bytes --]
> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha <libc-alpha@sourceware.org> wrote:
>
> Sam James <sam@gentoo.org> writes:
>>> On 11 Nov 2022, at 09:19, Florian Weimer <fweimer@redhat.com> wrote:
>>> We need to support legacy binaries on i386. Few libraries are
>>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
>>> to LFS or time64 needs to be evaluated on a per-library basis. For most
>>> distributions, no one is going to do that work, and we have to stick to
>>> whathever we are building today.
>>
>> While I agree, I don't think it's as well-known that it should be that
>> these are ABI breaking and require inspection. It's being done ad-hoc
>> or in many cases, not at all.
> …
>>>> We're now (possibly) on the eve of an autoconf 2.72 release which
>>>> contains two changes of note [2][3]
>>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>>>>
>>>> Indeed, the gnulib version of change #2 is exactly how we ended up with
>>>> wget/gnutls breaking [1]. I feel this shows that the only approach
>>>> "supported" by glibc right now is untenable.
>>>
>>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>>> for Fedora unfortunately.
>>>
>>> I thought the gnulib change has been reverted?
>>>
>>> I really wish the rest of GNU would talk to glibc maintainers before
>>> overriding glibc maintainer decisions.
>
> There seems to be a disconnect between Paul Eggert’s position on these
> changes and everyone else on this thread’s position.
>
> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.
> If an application is being built on the machine where it’ll be used, and
> both it and the system support building it with 64-bit time_t and off_t,
> *why wouldn’t you*? It has no impact on anything else to do that, and
> it future-proofs your installataion.
>
> But everyone else is worrying about cases where, either, an application
> is built with 64-bit time_t and/or off_t and then copied to a different
> system where the underlying libraries *don’t* support that, or a *shared
> library* is rebuilt with 64-bit time_t and/or off_t and that silently
> changes its ABI out from under programs that use it.
>
Precisely.
> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)
>
> (It’s also unfortunate that, 20+ years after the invention of ELF symbol
> versioning, it’s still ridiculously difficult. So many macros and
> assembly hacks and fighting with libtool. But I digress.)
>
> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038. That will
> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
> in order to unblock C23 testing — am I correct? It doesn’t resolve the
> larger issue, but it gives us more time to think about what the
> resolution ought to be.
>
> What do you think?
This is really I think the best option while allowing us time & space
to complete the larger discussion.
We keep AC_SYS_YEAR2038 which lets upstreams opt in,
but it avoids the risk of sudden LFS-into-time64 rollover.
Year 2038 work is really important (which is why I brought
up the topic) but I don't want confusion around it to make
people avoid adopting 2.72 or leave us without a 2.72
at all.
I do sympathise with Paul's position, but I'm not
a believer in piecemeal anyway now and it's fair to say there's no
consensus on this yet.
Paul's point Is fair that distros who wish can set the cache var to
ff, so *if* you and Paul want to keep it in.
I could live with a bigger "please check this!" in NEWS. I don't think it's a
total disaster as long as we brief distros first, as we're already
doing it for gnuilb & upstreams may well end up doing themselves,
so the train is on its way out of the station anyway.
(I think we need to keep the discussion going on that front,
but I think it'd be wrong to let it block this release, as it's
not a simple problem and I'm still unsure how I fully feel
about the issues at its core.)
I don't think it's conservative to make a macro suddenly
do a new thing which might require testing on the part
of projects using autoconf. Even if I get the aim.
And if we want to change it later, we still can. If we all
magically reach consensus in a month, there's nothing
stopping that being pursued.
So let's go for keep AC_SYS_YEAR2038 only?
Best,
sam
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 3:57 ` Sam James
@ 2022-11-12 14:16 ` Zack Weinberg
2022-11-12 17:41 ` Paul Eggert
0 siblings, 1 reply; 56+ messages in thread
From: Zack Weinberg @ 2022-11-12 14:16 UTC (permalink / raw)
To: Sam James
Cc: Florian Weimer, Paul Eggert, Carlos O'Donell via Libc-alpha,
autoconf, c-std-porting, toolchain, bug-gnulib
Sam James <sam@gentoo.org> writes:
>> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha <libc-alpha@sourceware.org> wrote:
>> I am honestly not sure what to do about this in the long term, but for
>> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
>> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
>> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038. That will
>> limit the impact of AC_SYS_YEAR2038 to packages that have explicitly
>> added it, and should make it safe for Fedora and Gentoo to drop in 2.72
>> in order to unblock C23 testing — am I correct? It doesn’t resolve the
>> larger issue, but it gives us more time to think about what the
>> resolution ought to be.
>>
>> What do you think?
>
> This is really I think the best option while allowing us time & space
> to complete the larger discussion.
[…]
I am going to go ahead and do this if nobody raises a concrete objection
within the next 24 hours.
zw
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 14:16 ` Zack Weinberg
@ 2022-11-12 17:41 ` Paul Eggert
2022-11-12 18:50 ` Bruno Haible
0 siblings, 1 reply; 56+ messages in thread
From: Paul Eggert @ 2022-11-12 17:41 UTC (permalink / raw)
To: Zack Weinberg, Sam James
Cc: Florian Weimer, Carlos O'Donell via Libc-alpha, autoconf,
c-std-porting, toolchain, bug-gnulib
On 2022-11-12 06:16, Zack Weinberg wrote:
> I am going to go ahead and do this if nobody raises a concrete objection
> within the next 24 hours.
I object to a simple reversion, as this will cause problems downstream
with Gnulib-using applications, several of which have already been
released assuming the current Autoconf git will go into the next
release, and which will stop working if built from Git with an Autoconf
2.72 where the AC_SYS_LARGEFILE changes have been reverted. Current
Gnulib assumes that AC_SYS_LARGEFILE will behave in Autoconf 2.72 like
what's in Git now. If we change AC_SYS_LARGFILE back, we will need to
change Gnulib too, and update downstream apps accordingly.
Instead, I suggest a partial reversion, in which AC_SYS_LARGEFILE goes
back to its previous meaning by default, but there is a well-documented
way to get the current in-Git meaning, a way that Gnulib can recognize
and use. For example, you'd get the new meaning if you configure with
--enable-year2038, or if configure.ac uses a new macro
AC_SYS_LARGER_FILE that supersedes AC_SYS_LARGEFILE. This will also
require some Gnulib changes, but they'll be more reliable and stable
than whipsaw changes required by reverting then whatever future changes
Autoconf makes.
This proposal would resolve the backward-compatibility concerns for
people who want to delay worrying about year-2038 issues, while also
resolving the compatibility concerns of Gnulib. It would also provide a
better-documented way for distros that want to switch to 64-bit time_t.
Of course this sort of thing cannot be written and tested in an hour.
But reverting is not that simple either, and would be a less efficient
use of everybody's time.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 17:41 ` Paul Eggert
@ 2022-11-12 18:50 ` Bruno Haible
2022-11-12 19:15 ` Paul Eggert
0 siblings, 1 reply; 56+ messages in thread
From: Bruno Haible @ 2022-11-12 18:50 UTC (permalink / raw)
To: Paul Eggert
Cc: Zack Weinberg, Sam James, Florian Weimer,
Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
toolchain, bug-gnulib
Paul Eggert wrote:
> On 2022-11-12 06:16, Zack Weinberg wrote:
> > I am going to go ahead and do this if nobody raises a concrete objection
> > within the next 24 hours.
>
> I object to a simple reversion, as this will cause problems downstream
> with Gnulib-using applications, several of which have already been
> released assuming the current Autoconf git will go into the next
> release, and which will stop working if built from Git with an Autoconf
> 2.72 where the AC_SYS_LARGEFILE changes have been reverted.
Paul, my assessment of Zack's proposed change is different. Things will
not "stop working". But rather, for packages
* that have been released in the last three months, with the then-newest
Gnulib,
* only when this package is reconfigured with Autoconf 2.72
then
(1) a portability problem to HP-UX/ia64 in 32-bit mode will appear,
(2) year 2038 compliance measures will not be enabled.
(1) is not something we need to worry about, since HP-UX/ia64 has so few
users, and why should them run 'autoreconf'.
(2) is a tiny setback on our journey to year 2038 compliance. I'm saying
"tiny" because we are still 15 years away, and new releases of the (not
many) affected packages are likely to come in the next 1-2 years.
My assessment is based on the understanding that Zack's proposed change
is essentially
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 0a9adba5..649d2d17 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -278,7 +278,7 @@ AS_IF([test "$enable_largefile" != no],
[Define for large files, on AIX-style hosts.],
[_AC_SYS_LARGEFILE_TEST_INCLUDES])],
[64],
- [_AC_SYS_YEAR2038()])])
+ [])])
AH_VERBATIM([__MINGW_USE_VC2005_COMPAT],
[#if !defined __MINGW_USE_VC2005_COMPAT && defined __MINGW32__
and upon inspection of the largefile.m4 part of this Gnulib commit:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=b9bf95fd0a6ab666b484b1e224321664f051f7fa
Bruno
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 18:50 ` Bruno Haible
@ 2022-11-12 19:15 ` Paul Eggert
2022-11-12 20:23 ` Wookey
0 siblings, 1 reply; 56+ messages in thread
From: Paul Eggert @ 2022-11-12 19:15 UTC (permalink / raw)
To: Bruno Haible
Cc: Zack Weinberg, Sam James, Florian Weimer,
Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
toolchain, bug-gnulib
On 2022-11-12 10:50, Bruno Haible wrote:
> I'm saying
> "tiny" because we are still 15 years away, and new releases of the (not
> many) affected packages are likely to come in the next 1-2 years.
Not so "tiny", I'm afraid. My department is still running a server with
libraries and executables that are over 17 years old. I have asked for
it to be decommissioned, but there are backward compatibility concerns.
(The OS is still supported by its supplier, and we install security
patches, most recently the day before yesterday.)
Admittedly my situation differs from embedded environments where
_TIME_BITS=64 is likely to make a difference 15 years from now.
Unfortunately the situation in embedded environments is often worse.
> My assessment is based on the understanding that Zack's proposed change
> is essentially [a small change to the code]
Yes, that's my understanding too. Unfortunately the Autoconf change
would have to be more complicated than that, since documentation and
comments would have to change accordingly. And the change to Gnulib code
would be considerably more complicated; this inevitably follows from any
significant change we make in this area to Autoconf on Savannah. I would
rather we spent our limited resources moving forward not backward.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 19:15 ` Paul Eggert
@ 2022-11-12 20:23 ` Wookey
2022-11-12 20:54 ` Russ Allbery
2022-11-12 21:31 ` Paul Eggert
0 siblings, 2 replies; 56+ messages in thread
From: Wookey @ 2022-11-12 20:23 UTC (permalink / raw)
To: Paul Eggert
Cc: Bruno Haible, Zack Weinberg, Sam James, Florian Weimer,
Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
toolchain, bug-gnulib, Arnd Bergmann
[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]
On 2022-11-12 11:15 -0800, Paul Eggert wrote:
> On 2022-11-12 10:50, Bruno Haible wrote:
> > I'm saying
> > "tiny" because we are still 15 years away, and new releases of the (not
> > many) affected packages are likely to come in the next 1-2 years.
>
> Not so "tiny", I'm afraid. My department is still running a server with
> libraries and executables that are over 17 years old.
Nobody disagrees with the idea that 2038 fixes are now fairly urgent
if we want to avoid real-world stuff breaking in 15 years time. That
has been increasingly clear for the last few years.
But the point here is that we need a bit of co-ordination and a plan,
particularly for binary distros. This isn't a minor change that should
just happen to people because there was an autoconf upgrade. Or at
least I don't think it is. My assumption is that if you just turned it
on in random packages as they were uploaded, there would be very
serious (unacceptably bad) breakage - we need to co-ordinate sets of
matching-ABI packages to upgrade together, and the worry is that the
matching set is 'most of the distro'.
Now, I'm not yet sure if just having autoconf 2.72 will actually break
things. AIUI, these changes only apply where LFS
(-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where
that is not the default on 32bit arches, maybe this is OK. But
probably quite a lot of packages already enable LFS so they are
suddenly going to get a new ABI if they expose timet anywhere?
https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows
163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is
used by a lot of packages (as you might expect - this transition has
been going on for many years). And just having that macro in
configure.(in|ac) will turn 64-bit timet on if you autoreconf with
2.72. Right?
We can't embark on that until we decide whether this transition will
be done within the existing arch/triplet or with a new one. I agree we
should decide that pronto. And I think that 'we' is bigger than just Debian.
If new autoconf (and gnulib) just turns this on within the existing
arch/triplet then we, the distro, can't use those new versions unless
we back out those changes, or until we decide that we are going to
attempt this ABI transition within the existing arch/triplet.
I'm OK with this being done either way (complicated transition within
arch/triplet, or whole-world rebuild with new arch/triplet) once the
size of the problem (and thus the amount of work) is reasonably
understood and there is some consensus amongst distros. TTBOMK we need
some more research before we can make that choice (although I realise
some others are further down this road than I am, and yes I did plan
to get to this point about a year ago, so apologies for
slowness). Hence my suggestion of a full discussion on the
cross-distro list. It is overdue.
However my limited understanding as of right now says that autoconf
2.72 tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72
can't be used in debian yet. So I currently favour not tying them
together in this release.
People have been using AC_SYS_LARGEFILE without 64bit time_t for many
years now so it's not yet clear to me why that cannot continue. And
even if it is a good idea to complete both transitions in the same
upheaval we can't just have everyone who enabled LFS sometime in the
last 20 years suddenly being forced into the time_t change (can we?).
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 20:23 ` Wookey
@ 2022-11-12 20:54 ` Russ Allbery
2022-11-12 21:31 ` Paul Eggert
1 sibling, 0 replies; 56+ messages in thread
From: Russ Allbery @ 2022-11-12 20:54 UTC (permalink / raw)
To: Wookey
Cc: Paul Eggert, Bruno Haible, Zack Weinberg, Sam James,
Florian Weimer, Carlos O'Donell via Libc-alpha, autoconf,
c-std-porting, toolchain, bug-gnulib, Arnd Bergmann
Wookey <wookey@wookware.org> writes:
> Now, I'm not yet sure if just having autoconf 2.72 will actually break
> things. AIUI, these changes only apply where LFS
> (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that
> is not the default on 32bit arches, maybe this is OK. But probably quite
> a lot of packages already enable LFS so they are suddenly going to get a
> new ABI if they expose timet anywhere?
> https://codesearch.debian.net/search?q=AC_SYS_LARGEFILE&perpkg=1 shows
> 163 pages of hits, and a quick peruse suggsts that AC_SYS_LARGEFILE is
> used by a lot of packages (as you might expect - this transition has
> been going on for many years). And just having that macro in
> configure.(in|ac) will turn 64-bit timet on if you autoreconf with
> 2.72. Right?
If indeed pre-existing use of AC_SYS_LARGEFILES would suddenly enable
64-bit time_t on autoreconf, I can name two packages just off the top of
my head that this change to Autoconf will immediately break if their
Debian packages are rebuilt with a newer version of Autoconf, creating
severe bugs.
libremctl will have its ABI changed without any coordination or versioning
(which I will be doing, moving forward, but have not started tackling yet
in part because I was waiting to see what the plan would be and whether
there will be some coordinated change to SONAMEs, a new architecture, or
what). And INN, which admittedly is a disaster about things like this for
lots of historical reasons, will have its *on-disk file format* changed
without notice in a way that will cause serious failure and possibly data
corruption on upgrades.
This is just wildly backward-incompatible and seems like an awful idea.
If we're going to throw a big switch and rebuild everything, it needs to
be done at a distro-wide level. I believe the only safe thing for
Autoconf to do is to provide an opt-in facility, similar to what was done
for AC_SYS_LARGEFILE, and then leave deciding whether to opt in to
higher-level machinery.
> However my limited understanding as of right now says that autoconf 2.72
> tying 64bit time_t to use of AC_SYS_LARGEFILE means that 2.72 can't be
> used in debian yet. So I currently favour not tying them together in
> this release.
That's also my understanding from the thread so far, although I'm not sure
that I'm following all of the subtleties.
> People have been using AC_SYS_LARGEFILE without 64bit time_t for many
> years now so it's not yet clear to me why that cannot continue.
And these are conceptually not at all the same thing. I saw Paul's
explanation for why he views them as fundamentally the same because of
their effect on system calls like stat, but I certainly don't think of
them that way and I am quite dubious many other people will either. The
set of things that I have to check to ensure that time_t is handled
correctly is totally different than the set of things I thought about when
enabling AC_SYS_LARGEFILE many years in the past.
I recognize that there will be overlap once file timestamps are past 2038
and that will happen sooner than anyone plans for, but it's still true
that this has *not* happened right now and this therefore is not currently
creating many bugs, whereas this switch in this way will create many, very
serious bugs immediately.
--
Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 20:23 ` Wookey
2022-11-12 20:54 ` Russ Allbery
@ 2022-11-12 21:31 ` Paul Eggert
2022-11-15 5:09 ` Sam James
1 sibling, 1 reply; 56+ messages in thread
From: Paul Eggert @ 2022-11-12 21:31 UTC (permalink / raw)
To: Wookey
Cc: Bruno Haible, Zack Weinberg, Sam James, Florian Weimer,
Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
toolchain, bug-gnulib, Arnd Bergmann
On 2022-11-12 12:23, Wookey wrote:
> we can't just have everyone who enabled LFS sometime in the
> last 20 years suddenly being forced into the time_t change (can we?)
We've done it in the past.
AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to
Autoconf. Originally it affected only off_t; its effect on other types
like ino_t came later. Hence people who initially used AC_SYS_LARGEFILE
were later "suddenly forced" into an ino_t width change. Similarly for
other non-off_t types that AC_SYS_LARGEFILE affects.
So there's longstanding precedent for AC_SYS_LARGEFILE changing the
width of system types that were formerly unaffected. The difference is
that time_t is more widely used than ino_t etc., and people are
understandably more concerned about time_t changes.
Because of the concerns raised in this thread it's become clear that
what's in Autoconf now is too drastic, and I've proposed (though not yet
implemented) a change that will cause AC_SYS_LARGEFILE to continue to
not affect time_t unless there's an affirmative request like
"./configure --enable-year2038". I am waiting for feedback on that from
Zack and others, and am hoping for quick turnaround on this because we
do need a new Autoconf release.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 21:31 ` Paul Eggert
@ 2022-11-15 5:09 ` Sam James
0 siblings, 0 replies; 56+ messages in thread
From: Sam James @ 2022-11-15 5:09 UTC (permalink / raw)
To: Paul Eggert, Carlos O'Donell via Libc-alpha
Cc: Wookey, Bruno Haible, Zack Weinberg, Florian Weimer,
Autoconf Development, c-std-porting, Gentoo Toolchain,
Gnulib bugs, Arnd Bergmann
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
> On 12 Nov 2022, at 21:31, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> On 2022-11-12 12:23, Wookey wrote:
>> we can't just have everyone who enabled LFS sometime in the
>> last 20 years suddenly being forced into the time_t change (can we?)
>
> We've done it in the past.
>
> AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. Originally it affected only off_t; its effect on other types like ino_t came later. Hence people who initially used AC_SYS_LARGEFILE were later "suddenly forced" into an ino_t width change. Similarly for other non-off_t types that AC_SYS_LARGEFILE affects.
>
> So there's longstanding precedent for AC_SYS_LARGEFILE changing the width of system types that were formerly unaffected. The difference is that time_t is more widely used than ino_t etc., and people are understandably more concerned about time_t changes.
>
Thanks, that's a helpful bit of history I wasn't aware of there.
>
> Because of the concerns raised in this thread it's become clear that what's in Autoconf now is too drastic, and I've proposed (though not yet implemented) a change that will cause AC_SYS_LARGEFILE to continue to not affect time_t unless there's an affirmative request like "./configure --enable-year2038". I am waiting for feedback on that from Zack and others, and am hoping for quick turnaround on this because we do need a new Autoconf release.
>
>
Sorry, I missed this until now.
That would work well for me too. It's fine for me at least if the same macro just haas additional compatibilities, even if a bit confusing
at first.
As for further changes (as the original post wasn't exclusive to autoconf),
I await comment from other glibc maintainers as I still feel like we're
pretty stuck about how to handle this overall. But your suggestion
(or zw's patch) puts out or dampens the autoconf fire at least.
Thanks for helping come to a compromise. I know this isn't
a simple or easy topic at all.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 2:20 ` Zack Weinberg
2022-11-12 3:57 ` Sam James
@ 2022-11-12 18:19 ` Paul Eggert
1 sibling, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2022-11-12 18:19 UTC (permalink / raw)
To: Zack Weinberg, Sam James
Cc: Florian Weimer, libc-alpha, autoconf, c-std-porting, toolchain,
bug-gnulib
On 2022-11-11 18:20, Zack Weinberg wrote:
> I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be
> overriding the glibc maintainers. Rather, I think he was only thinking
> about applications, not libraries, and only about source distribution.
No, I was thinking about libraries as well. Although there are problems
with libraries and time_t, for decades we've had the same problems with
AC_SYS_LARGEFILE and off_t, rlim_t, ino_t, etc. Why should time_t be
treated differently from the other types?
> (It’s unfortunate, IMNSHO, that glibc chose not to provide a time_t
> equivalent of _LARGEFILE64_SOURCE, as this means it’s much more
> difficult for any shared library other than glibc to offer *both* time_t
> and time64_t binary interfaces.)
I can easily understand why glibc didn't take that approach. The LFS API
designed in the mid-1990s to support both off_t and off64_t in
user-level code was supposed to be a "transitional API", but we're still
stuck with it nearly 30 years later, even though almost nobody uses it
(and the few who do often don't use it correctly). Even if we weren't
dissuaded by the problems of the LFS API, we won't have a luxury of a
30-year transition for time_t, as we're only 15 years away from 2038.
More generally, the LFS API approach doesn't scale, as the complexity of
the implementation would grow exponentially with the number of features
involved. Nobody wants to implement or support that sort of thing. This
is why glibc put rlimt_t, ino_t, etc. under the off_t umbrella.
> I am honestly not sure what to do about this in the long term, but for
> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it
> makes sense to back out change #2, only — that is, AC_SYS_YEAR2038 will
> exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038.
AC_SYS_LARGEFILE doesn't imply AC_SYS_YEAR2038 now, in Autoconf git.
Things are a bit more complicated, unfortunately.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:19 ` Florian Weimer
2022-11-11 9:27 ` Sam James
@ 2022-11-11 9:40 ` Andreas K. Huettel
2022-11-11 11:30 ` Florian Weimer
2022-11-11 9:46 ` Paul Eggert
` (2 subsequent siblings)
4 siblings, 1 reply; 56+ messages in thread
From: Andreas K. Huettel @ 2022-11-11 9:40 UTC (permalink / raw)
To: Sam James, libc-alpha
Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Paul Eggert, Frederic Berat, Florian Weimer
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
> >
> > Proposal: glibc gains two new build-time configure options:
> > * --enable-hard-time64
> > * --enable-hard-lfs
>
> We should define new target triplets for this if it's really required.
>
That doesn't really help anyone *but* Debian ...
> We need to support legacy binaries on i386. Few libraries are
> explicitly dual-ABI. Whether it's safe to switch libraries above
> glibc to LFS or time64 needs to be evaluated on a per-library
> basis. For most distributions, no one is going to do that work,
> and we have to stick to whathever we are building today.
... since for Debian the libraries with different ABI end up in different
multiarch paths then.
Anyone with a more, ahem, standard filesystem arrangement has to find
a different solution for the problem of legacy binaries.
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:40 ` Andreas K. Huettel
@ 2022-11-11 11:30 ` Florian Weimer
2022-11-11 19:01 ` Andreas K. Huettel
0 siblings, 1 reply; 56+ messages in thread
From: Florian Weimer @ 2022-11-11 11:30 UTC (permalink / raw)
To: Andreas K. Huettel
Cc: Sam James, libc-alpha, autoconf, c-std-porting, Zack Weinberg,
David Seifert, Gentoo Toolchain, Arsen Arsenović,
Paul Eggert, Frederic Berat
* Andreas K. Huettel:
>> >
>> > Proposal: glibc gains two new build-time configure options:
>> > * --enable-hard-time64
>> > * --enable-hard-lfs
>>
>> We should define new target triplets for this if it's really required.
>>
>
> That doesn't really help anyone *but* Debian ...
>
>> We need to support legacy binaries on i386. Few libraries are
>> explicitly dual-ABI. Whether it's safe to switch libraries above
>> glibc to LFS or time64 needs to be evaluated on a per-library
>> basis. For most distributions, no one is going to do that work,
>> and we have to stick to whathever we are building today.
>
> ... since for Debian the libraries with different ABI end up in different
> multiarch paths then.
I didn't expect co-installability as a requirement. But yes, if that's
the goal, we need non-overlapping paths.
> Anyone with a more, ahem, standard filesystem arrangement has to find
> a different solution for the problem of legacy binaries.
We can have lib, lib64, libx32, and lib32t quite easily, that's not the
problem. What's missing is ldconfig support. The previous three x86
architectures have ELF-level selectors; we might need something special
there as well.
Debian does not have a multi-arch ldconfig, either. Their path layout
isn't really ideal for that because it lacks a marker directory like
glibc-hwcaps that would allow ldconfig to build the cache from file
system content without knowledge of the exact architecture list.
Maybe I can get justification for upstreaming some form of multi-arch
support in the toolchain. But I find it difficult to make this a top
priority. (We currently use the upstream path layout in our
distributions.)
Thanks,
Florian
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 11:30 ` Florian Weimer
@ 2022-11-11 19:01 ` Andreas K. Huettel
2022-11-11 19:28 ` Palmer Dabbelt
0 siblings, 1 reply; 56+ messages in thread
From: Andreas K. Huettel @ 2022-11-11 19:01 UTC (permalink / raw)
To: Florian Weimer
Cc: Sam James, libc-alpha, autoconf, c-std-porting, Zack Weinberg,
David Seifert, Gentoo Toolchain, Arsen Arsenović,
Paul Eggert, Frederic Berat
> >> We need to support legacy binaries on i386. Few libraries are
> >> explicitly dual-ABI. Whether it's safe to switch libraries above
> >> glibc to LFS or time64 needs to be evaluated on a per-library
> >> basis. For most distributions, no one is going to do that work,
> >> and we have to stick to whathever we are building today.
> >
> > ... since for Debian the libraries with different ABI end up in different
> > multiarch paths then.
>
> I didn't expect co-installability as a requirement. But yes, if that's
> the goal, we need non-overlapping paths.
Doesn't that requirement come automatically with "we need to support legacy
binaries"? How else would that work?
> > Anyone with a more, ahem, standard filesystem arrangement has to find
> > a different solution for the problem of legacy binaries.
>
> We can have lib, lib64, libx32, and lib32t quite easily, that's not the
> problem. What's missing is ldconfig support. The previous three x86
> architectures have ELF-level selectors; we might need something special
> there as well.
Yup. I was thinking of lib32n (which won't collide with anything out
there), but the selector problem remains.
[Apart from all further fun problems with library paths unexpected by
unwary upstreams... riscv64 (lib64/lp64d, lib64/lp64, lib32/ilp32d,
lib32/ilp32) and mips64 (lib, lib32, lib64) send their regards.]
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 19:01 ` Andreas K. Huettel
@ 2022-11-11 19:28 ` Palmer Dabbelt
0 siblings, 0 replies; 56+ messages in thread
From: Palmer Dabbelt @ 2022-11-11 19:28 UTC (permalink / raw)
To: libc-alpha
Cc: fweimer, sam, libc-alpha, autoconf, c-std-porting, zack, soap,
toolchain, arsen, eggert, fberat
On Fri, 11 Nov 2022 11:01:50 PST (-0800), libc-alpha@sourceware.org wrote:
>> >> We need to support legacy binaries on i386. Few libraries are
>> >> explicitly dual-ABI. Whether it's safe to switch libraries above
>> >> glibc to LFS or time64 needs to be evaluated on a per-library
>> >> basis. For most distributions, no one is going to do that work,
>> >> and we have to stick to whathever we are building today.
>> >
>> > ... since for Debian the libraries with different ABI end up in different
>> > multiarch paths then.
>>
>> I didn't expect co-installability as a requirement. But yes, if that's
>> the goal, we need non-overlapping paths.
>
> Doesn't that requirement come automatically with "we need to support legacy
> binaries"? How else would that work?
>
>> > Anyone with a more, ahem, standard filesystem arrangement has to find
>> > a different solution for the problem of legacy binaries.
>>
>> We can have lib, lib64, libx32, and lib32t quite easily, that's not the
>> problem. What's missing is ldconfig support. The previous three x86
>> architectures have ELF-level selectors; we might need something special
>> there as well.
>
> Yup. I was thinking of lib32n (which won't collide with anything out
> there), but the selector problem remains.
>
> [Apart from all further fun problems with library paths unexpected by
> unwary upstreams... riscv64 (lib64/lp64d, lib64/lp64, lib32/ilp32d,
> lib32/ilp32) and mips64 (lib, lib32, lib64) send their regards.]
I don't want to derail the thread, but sorry again for the RISC-V bits
there. IMO we can fix it without an ABI break via adding some new
paths, I just don't know what they should be. Happy to hear if anyone
has suggestions...
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:19 ` Florian Weimer
2022-11-11 9:27 ` Sam James
2022-11-11 9:40 ` Andreas K. Huettel
@ 2022-11-11 9:46 ` Paul Eggert
2022-11-11 11:22 ` Florian Weimer
2022-11-12 4:20 ` Wookey
2022-11-14 8:39 ` Adam Sampson
4 siblings, 1 reply; 56+ messages in thread
From: Paul Eggert @ 2022-11-11 9:46 UTC (permalink / raw)
To: Florian Weimer, Sam James
Cc: Carlos O'Donell via Libc-alpha, autoconf, c-std-porting,
Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Frederic Berat
On 2022-11-11 01:19, Florian Weimer wrote:
> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
>
> I thought the gnulib change has been reverted?
I'm not sure where you got that impression. Bleeding-edge (unreleased)
Autoconf AC_SYS_LARGEFILE, along with Gnulib AS_SYS_LARGEFILE as shipped
in several GNU apps already, default to 64-bit time_t on platforms where
setting _TIME_BITS=64 changes time_t from 32 to 64 bits. (This is not
the same as defaulting to AC_SYS_YEAR2038 which *requires*
wider-than-32-bit time_t, but I expect the difference doesn't matter here.)
> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions. If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port. Debian will probably be impacted in the same way.
I'm not sure what is meant by "overriding", as Autoconf etc. are merely
using a documented glibc feature. Also, the apps in question can be
configured to stick with 32-bit time_t by using "./configure
--disable-year2038" and/or setting the corresponding cache variables, so
distros continue to have a choice about which time_t flavor they prefer.
What I'm gathering from your email is that 32-bit Fedora x86 needs an
easy way to say "hold on, I want 32-bit time_t to be the default for all
'configure' runs". If the --disable-year2038 option of 'configure' isn't
enough, and/or setting the appropriate cache variables isn't enough,
what other configuration method would you like?
Also, how does this issue with 64-bit time_t differ from the decades-old
issue with 64-bit off_t? AC_SYS_LARGEFILE has long defaulted to 64-bit
off_t, and Autoconf-generated configure scripts have long had
--disable-largefile options and related cache variables much the same
way that they're now dealing with 64-bit time_t. Is the difference
merely that time_t is more widely used than off_t, so the ABI problems
are more likely now?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:46 ` Paul Eggert
@ 2022-11-11 11:22 ` Florian Weimer
2022-11-11 19:56 ` Paul Eggert
0 siblings, 1 reply; 56+ messages in thread
From: Florian Weimer @ 2022-11-11 11:22 UTC (permalink / raw)
To: Paul Eggert
Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Frederic Berat
* Paul Eggert:
> On 2022-11-11 01:19, Florian Weimer wrote:
>
>> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
>> for Fedora unfortunately.
>> I thought the gnulib change has been reverted?
>
> I'm not sure where you got that impression. Bleeding-edge (unreleased)
> Autoconf AC_SYS_LARGEFILE, along with Gnulib AS_SYS_LARGEFILE as
> shipped in several GNU apps already, default to 64-bit time_t on
> platforms where setting _TIME_BITS=64 changes time_t from 32 to 64
> bits. (This is not the same as defaulting to AC_SYS_YEAR2038 which
> *requires* wider-than-32-bit time_t, but I expect the difference
> doesn't matter here.)
Ugh.
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions. If we cannot revert this in
>> autoconf (and gnulib), this will very much endanger the Fedora i386
>> port. Debian will probably be impacted in the same way.
>
> I'm not sure what is meant by "overriding", as Autoconf etc. are
> merely using a documented glibc feature. Also, the apps in question
> can be configured to stick with 32-bit time_t by using "./configure
> --disable-year2038" and/or setting the corresponding cache variables,
> so distros continue to have a choice about which time_t flavor they
> prefer.
There are many documented toolchain features that change ABI. It's up
to developers to determine whether it's safe to enable them. For Y2038
support, that's obviously quite desirable in principle. But we (glibc
upstream) looked at it and concluded that we just can't introduce it by
default and maintain backwards compatibility with existing binaries,
which is of paramount importance for i386.
I never expected GNU to switch i386 to time64 by default. Attempting
this switch is a huge distraction and prevents many of us from working
on more important matters that benefit GNU in much more direct ways.
> What I'm gathering from your email is that 32-bit Fedora x86 needs an
> easy way to say "hold on, I want 32-bit time_t to be the default for
> all 'configure' runs". If the --disable-year2038 option of 'configure'
> isn't enough, and/or setting the appropriate cache variables isn't
> enough, what other configuration method would you like?
I don't know yet. Fortunately, any issues should be quite visibile in
the distribution DWARF data. If we put the time32 switch in place, we
should be able to tell whether it's effective enough in practice.
> Also, how does this issue with 64-bit time_t differ from the
> decades-old issue with 64-bit off_t? AC_SYS_LARGEFILE has long
> defaulted to 64-bit off_t, and Autoconf-generated configure scripts
> have long had --disable-largefile options and related cache variables
> much the same way that they're now dealing with 64-bit time_t. Is the
> difference merely that time_t is more widely used than off_t, so the
> ABI problems are more likely now?
LFS issues have been with us for a long time, and packages and
distributions have workarounds for it (e.g., using off64_t or long long
in public headers). What we have today mostly works. But it's unknown
whether existing AC_SYS_LARGEFILE users require any additional work for
time64 changes. It's also not clear how to approach this from an
individual upstream perspective if different distributions have
different requirements. I just don't see many libraries adopting a
dual-ABI approach like glibc did, or spending much work on this.
Thanks,
Florian
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 11:22 ` Florian Weimer
@ 2022-11-11 19:56 ` Paul Eggert
0 siblings, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2022-11-11 19:56 UTC (permalink / raw)
To: Florian Weimer
Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Frederic Berat
On 2022-11-11 03:22, Florian Weimer wrote:
> Fortunately, any issues should be quite visibile in
> the distribution DWARF data. If we put the time32 switch in place, we
> should be able to tell whether it's effective enough in practice.
OK, thanks; if problems turn up in that area please let the
Autoconf/Gnulib people know what we can do to help address them.
> LFS issues have been with us for a long time, and packages and
> distributions have workarounds for it (e.g., using off64_t or long long
> in public headers). What we have today mostly works. But it's unknown
> whether existing AC_SYS_LARGEFILE users require any additional work for
> time64 changes.
If what we have today mostly works, then it works for blkcnt_t, dev_t,
ino_t, off_t and rlim_t, all of whose widths differ on 32-bit x86 glibc
depending on whether one compiles with -D_FILE_OFFSET_BITS=64. So
there's some precedent for hoping that what we have today will mostly
work for time_t and -D_TIME_BITS=64 as well.
In hindsight, perhaps it would have been better to have
_FILE_OFFSET_BITS=64 also control time_t width, since that would have
made for one less configure-time option to worry about. (After all
rlim_t can hold 64-bit counts of seconds, so why not time_t?) I suppose
it's too late for that now, though.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:19 ` Florian Weimer
` (2 preceding siblings ...)
2022-11-11 9:46 ` Paul Eggert
@ 2022-11-12 4:20 ` Wookey
2022-11-12 4:28 ` Sam James
2022-11-12 18:33 ` Paul Eggert
2022-11-14 8:39 ` Adam Sampson
4 siblings, 2 replies; 56+ messages in thread
From: Wookey @ 2022-11-12 4:20 UTC (permalink / raw)
To: Florian Weimer
Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 5293 bytes --]
On 2022-11-11 10:19 +0100, Florian Weimer wrote:
Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf
in Debian. We are currently doing a preliminary bootstrap to see what
breaks. We strongly suspect that only a wholesale rebuild for the new
ABI (i.e a new Debian architecture) is practical, but have not yet
entirely ruled out attempting a migration within the existing armhf
arch.
A test of this in 2020 by Arnd Bergman found that too much stuff was broken.
https://lists.debian.org/debian-arm/2020/02/msg00024.html
Things now look much more mature as some others have already fixed various things.
https://lists.debian.org/debian-arm/2022/09/msg00012.html
https://lists.debian.org/debian-arm/2022/10/msg00020.html
I've not got far with bootstrapping but had got as for as noting that
LFS and 64bit timet are tied together in glibc (setting _TIME_BITS=64
requires setting _FILE_OFFSET_BITS=64). So that's two lots of
interacting ABI changes, which doesn't make things any simpler.
> * Sam James
>
> > In Gentoo, we've been planning out what we should do for time64 on
> > glibc [0] and concluded that we need some support in glibc for a newer
> > option. I'll outline why below.
> >
> > Proposal: glibc gains two new build-time configure options:
> > * --enable-hard-time64
> > * --enable-hard-lfs
I don't quite follow the logic of this. glibc already has build-time macros to set these two things:
_TIME_BITS=64
_FILE_OFFSET_BITS=64
why do we need configure options too?
> We should define new target triplets for this if it's really required.
We have been coming to the conclusion that this is necessary. If it's
not feasible to migrate with the existing armhf (and maybe i386)
architectures, then we need a new triplet to define this ABI and (in
debian, match the dkpg arch name).
> We need to support legacy binaries on i386. Few libraries are
> explicitly dual-ABI. Whether it's safe to switch libraries above glibc
> to LFS or time64 needs to be evaluated on a per-library basis. For most
> distributions, no one is going to do that work, and we have to stick to
> whathever we are building today.
Well Debian has started this work.
> > These would hard-enable the relevant #defines within glibc's headers
> > and ensure that any binaries built with such a glibc have both Large
> > File Support (LFS) and time64 support.
> >
> > I've come to the conclusion it's infeasible to try handle the
> > migration piecemeal. Various mismatches can and will occur (and while
> > it's more likely with time64, it's possible with LFS too) [1].
Right. This is definitely a problem, as both items will be in structs
that are exposed in ABIs in various places. What I've not yet got a
handle on is just how big a problem. Debian has done large ABI
transitions before within an architecture (glibc5->6), (GCC 4.0 C++
ABI), and (long-double transition (from 64 to 128 bits), on a subset of arches), so it is
possible. (That long-double transition is the most like this
transition, because it involves types that can appear in C and C++
ABI). https://lists.debian.org/debian-devel/2007/05/msg01173.html
> > We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
> > of note [2][3]
> > 1. addition of a new AC_SYS_YEAR2038 macro;
> > 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
Which is the opposite way round to glibc, where _TIME_BITS=64 requires
_FILE_OFFSET_BITS=64, but not the other way round
(_FILE_OFFSET_BITS=64, can be set on its own). Am I misunderstanding something here?
It doesn't seem right to me that AC_SYS_LARGEFILE should imply
AC_SYS_YEAR2038. What is the reasoning behind that?
> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions. If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port. Debian will probably be impacted in the same way.
I need to read around all this as I have only just become aware that
the LFS thing is entangled with the timet_64 thing. Is there a good
place to read _why_ one implies the other? It definitely complicates
matters.
> > On reflection and after extensive discussion within Gentoo (although
> > I don't seek to speak for everybody there) - with special thanks to
> > David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
> > we don't think it's feasible to handle this in a piecemeal fashion -
> > at the very least not without spending a significant & for some,
> > undesirable amount of time on supporting "obsolete" 32-bit platforms.
Distros need to co-ordinate on this. If there are going to be new
triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
them and use them. If distros are happy to migrate to these ABIs
within the existing arm-linux-gnueabihf and i386-linux-gnu (or
i686-linux-gnu) then we should do that.
If half the distros migrate within the existing triplet and the rest use
a new one, that sounds like a recipie for much confusion.
I could write more, but I'll swot up a bit first :-)
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 4:20 ` Wookey
@ 2022-11-12 4:28 ` Sam James
2022-11-12 4:56 ` Wookey
2022-11-12 18:33 ` Paul Eggert
1 sibling, 1 reply; 56+ messages in thread
From: Sam James @ 2022-11-12 4:28 UTC (permalink / raw)
To: Wookey
Cc: Florian Weimer, Carlos O'Donell via Libc-alpha,
Autoconf Development, c-std-porting, Zack Weinberg,
David Seifert, Gentoo Toolchain, Arsen Arsenović,
Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 4212 bytes --]
> On 12 Nov 2022, at 04:20, Wookey <wookey@wookware.org> wrote:
>
> On 2022-11-11 10:19 +0100, Florian Weimer wrote:
>
> Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf
> in Debian. We are currently doing a preliminary bootstrap to see what
> breaks. We strongly suspect that only a wholesale rebuild for the new
> ABI (i.e a new Debian architecture) is practical, but have not yet
> entirely ruled out attempting a migration within the existing armhf
> arch.
>
> [snip]
>
>> * Sam James
>>
>>> In Gentoo, we've been planning out what we should do for time64 on
>>> glibc [0] and concluded that we need some support in glibc for a newer
>>> option. I'll outline why below.
>>>
>>> Proposal: glibc gains two new build-time configure options:
>>> * --enable-hard-time64
>>> * --enable-hard-lfs
>
> I don't quite follow the logic of this. glibc already has build-time macros to set these two things:
> _TIME_BITS=64
> _FILE_OFFSET_BITS=64
>
> why do we need configure options too?
How do you make sure that every program built uses it? Not every
program respects CPPFLAGS and even in CFLAGS, it's a bit
of a nuisance.
If you patch GCC, you don't cover Clang. If you patch system
compilers, that's messy but also doesn't help with custom-built programs.
Of course, we could just patch glibc and cheerily jam it in the headers,
but we run into the kind of problems that Joseph Myers mentions then,
I think (basically I'd want to make sure we do it right.)
>
>>> We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes
>>> of note [2][3]
>>> 1. addition of a new AC_SYS_YEAR2038 macro;
>>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038.
>
> Which is the opposite way round to glibc, where _TIME_BITS=64 requires
> _FILE_OFFSET_BITS=64, but not the other way round
> (_FILE_OFFSET_BITS=64, can be set on its own). Am I misunderstanding something here?
>
I wonder the same. I don't think it's obvious, and it may not be obvious
to people writing software using autoconf either...
> It doesn't seem right to me that AC_SYS_LARGEFILE should imply
> AC_SYS_YEAR2038. What is the reasoning behind that?
>
>> I really wish the rest of GNU would talk to glibc maintainers before
>> overriding glibc maintainer decisions. If we cannot revert this in
>> autoconf (and gnulib), this will very much endanger the Fedora i386
>> port. Debian will probably be impacted in the same way.
>
> I need to read around all this as I have only just become aware that
> the LFS thing is entangled with the timet_64 thing. Is there a good
> place to read _why_ one implies the other? It definitely complicates
> matters.
time64 has to imply LFS because of some structures like stat including
both off_t (LFS) and st_atim (time64), I think. Some of it is internal too.
Or do you mean LFS => time64? I have no idea for why that's
entangled in autoconf and gnulib.
>
>>> On reflection and after extensive discussion within Gentoo (although
>>> I don't seek to speak for everybody there) - with special thanks to
>>> David Seifert and Arsen Arsenović for tolerating my bikesheds on this,
>>> we don't think it's feasible to handle this in a piecemeal fashion -
>>> at the very least not without spending a significant & for some,
>>> undesirable amount of time on supporting "obsolete" 32-bit platforms.
>
> Distros need to co-ordinate on this. If there are going to be new
> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
> them and use them. If distros are happy to migrate to these ABIs
> within the existing arm-linux-gnueabihf and i386-linux-gnu (or
> i686-linux-gnu) then we should do that.
>
> If half the distros migrate within the existing triplet and the rest use
> a new one, that sounds like a recipie for much confusion.
>
100%. And also on sharing patches and known problems
and experience with the migration. All of it!
> I could write more, but I'll swot up a bit first :-)
It's not easy to find much about all of this! I almost
felt like I was missing something at first. :)
Best,
sam
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 4:28 ` Sam James
@ 2022-11-12 4:56 ` Wookey
2022-11-12 4:59 ` Sam James
0 siblings, 1 reply; 56+ messages in thread
From: Wookey @ 2022-11-12 4:56 UTC (permalink / raw)
To: Sam James
Cc: Florian Weimer, Carlos O'Donell via Libc-alpha,
Autoconf Development, c-std-porting, Zack Weinberg,
David Seifert, Gentoo Toolchain, Arsen Arsenović,
Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
On 2022-11-12 04:28 +0000, Sam James wrote:
>
>
> > On 12 Nov 2022, at 04:20, Wookey <wookey@wookware.org> wrote:
> >
> > Distros need to co-ordinate on this. If there are going to be new
> > triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
> > them and use them. If distros are happy to migrate to these ABIs
> > within the existing arm-linux-gnueabihf and i386-linux-gnu (or
> > i686-linux-gnu) then we should do that.
> >
> > If half the distros migrate within the existing triplet and the rest use
> > a new one, that sounds like a recipie for much confusion.
> >
>
> 100%. And also on sharing patches and known problems
> and experience with the migration. All of it!
OK. It seems that the time is right to have this conversation. So we should agree on a place to do it.
We have used the linaro cross-distro list in the past as it is
intended for this sort of cross-cutting discussions. I can't think of
a better place?
https://lists.linaro.org/mailman3/lists/cross-distro.lists.linaro.org/
Some of the right people are probably already there, but we should
encourage others with relevant expertise to join.
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 4:56 ` Wookey
@ 2022-11-12 4:59 ` Sam James
0 siblings, 0 replies; 56+ messages in thread
From: Sam James @ 2022-11-12 4:59 UTC (permalink / raw)
To: Wookey
Cc: Florian Weimer, Carlos O'Donell via Libc-alpha,
Autoconf Development, c-std-porting, Zack Weinberg,
David Seifert, Gentoo Toolchain, Arsen Arsenović,
Paul Eggert, Frederic Berat, Arnd Bergmann, Helmut Grohne
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
> On 12 Nov 2022, at 04:56, Wookey <wookey@wookware.org> wrote:
>
> On 2022-11-12 04:28 +0000, Sam James wrote:
>>
>>
>>> On 12 Nov 2022, at 04:20, Wookey <wookey@wookware.org> wrote:
>>>
>>> Distros need to co-ordinate on this. If there are going to be new
>>> triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on
>>> them and use them. If distros are happy to migrate to these ABIs
>>> within the existing arm-linux-gnueabihf and i386-linux-gnu (or
>>> i686-linux-gnu) then we should do that.
>>>
>>> If half the distros migrate within the existing triplet and the rest use
>>> a new one, that sounds like a recipie for much confusion.
>>>
>>
>> 100%. And also on sharing patches and known problems
>> and experience with the migration. All of it!
>
> OK. It seems that the time is right to have this conversation. So we should agree on a place to do it.
>
> We have used the linaro cross-distro list in the past as it is
> intended for this sort of cross-cutting discussions. I can't think of
> a better place?
> https://lists.linaro.org/mailman3/lists/cross-distro.lists.linaro.org/
>
> Some of the right people are probably already there, but we should
> encourage others with relevant expertise to join.
>
That list is new to me (sub'd now) but I'm fine with using it as long
as linaro are still OK with us using it and them maintaining it.
Thanks for taking the initiative!
If they aren't, we could request a list from lists.linux.dev
(Linux Foundation).
Best,
sam
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-12 4:20 ` Wookey
2022-11-12 4:28 ` Sam James
@ 2022-11-12 18:33 ` Paul Eggert
1 sibling, 0 replies; 56+ messages in thread
From: Paul Eggert @ 2022-11-12 18:33 UTC (permalink / raw)
To: Wookey, Florian Weimer
Cc: Sam James, Carlos O'Donell via Libc-alpha, autoconf,
c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Frederic Berat, Arnd Bergmann, Helmut Grohne
On 2022-11-11 20:20, Wookey wrote:
> It doesn't seem right to me that AC_SYS_LARGEFILE should imply
> AC_SYS_YEAR2038. What is the reasoning behind that?
First, in Autoconf git AC_SYS_LARGEFILE does not imply AC_SYS_YEAR2038.
The former is willing to fall back on 32-bit time_t if 64-bit is not
available. The latter errors out unless 64-bit time_t is available.
Second and to answer your question, the intent of AC_SYS_LARGEFILE has
always been, "I want open, stat, lseek, etc. to work on all files, and I
don't want them to fail with errno==EOVERFLOW simply because my integer
types are too narrow".
For this to work with glibc 2.34+ on x64 and arm GNU/Linux, time_t must
be 64 bits just as off_t, dev_t etc must be 64 bits; otherwise syscalls
like 'stat' stop working on some files. These failures can have security
implications. Many software developers, even in the security arena,
haven't thought through the implications of EOVERFLOW and their programs
do the wrong thing with EOVERFLOW.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-11 9:19 ` Florian Weimer
` (3 preceding siblings ...)
2022-11-12 4:20 ` Wookey
@ 2022-11-14 8:39 ` Adam Sampson
2022-11-14 11:47 ` Florian Weimer
2022-11-14 20:26 ` Arsen Arsenović
4 siblings, 2 replies; 56+ messages in thread
From: Adam Sampson @ 2022-11-14 8:39 UTC (permalink / raw)
To: Florian Weimer via Libc-alpha
Cc: Sam James, Florian Weimer, autoconf, c-std-porting,
Zack Weinberg, David Seifert, Gentoo Toolchain,
Arsen Arsenović,
Paul Eggert, Frederic Berat
Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
> We should define new target triplets for this if it's really required.
If the consensus on this does come down to the definition of new
architecture triplets, are there any other changes that should (or
could) be made at the same time, beyond time64 and LFS?
Thanks,
--
Adam Sampson <ats@offog.org> <http://offog.org/>
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-14 8:39 ` Adam Sampson
@ 2022-11-14 11:47 ` Florian Weimer
2022-11-14 20:26 ` Arsen Arsenović
1 sibling, 0 replies; 56+ messages in thread
From: Florian Weimer @ 2022-11-14 11:47 UTC (permalink / raw)
To: Adam Sampson via Libc-alpha
Cc: Adam Sampson, Sam James, autoconf, c-std-porting, Zack Weinberg,
David Seifert, Gentoo Toolchain, Arsen Arsenović,
Paul Eggert, Frederic Berat
* Adam Sampson via Libc-alpha:
> Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> We should define new target triplets for this if it's really required.
>
> If the consensus on this does come down to the definition of new
> architecture triplets, are there any other changes that should (or
> could) be made at the same time, beyond time64 and LFS?
I don't think there are any other non-controversial changes for
i386-linux-gnu (relative to the current i386-linux-gnu interpretation,
i.e. with SSE2 stack alignment). Lots and lots of glibc compat symbols
will be dropped, but that should be a transparent change (and something
you would be exposed through mere recompilation against current glibc).
It seems it would be an opportunity to clean up the Arm triplets and
define the ISAs/ABIs for the new ones more tightly than what's been
previously used. But I have zero insight into which ISAs/ABIs would be
required.
I don't know if any of the legacy 32-bit ABIs would benefit from similar
clarification.
Thanks,
Florian
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-14 8:39 ` Adam Sampson
2022-11-14 11:47 ` Florian Weimer
@ 2022-11-14 20:26 ` Arsen Arsenović
2022-11-14 20:52 ` Florian Weimer
1 sibling, 1 reply; 56+ messages in thread
From: Arsen Arsenović @ 2022-11-14 20:26 UTC (permalink / raw)
To: Adam Sampson
Cc: Florian Weimer via Libc-alpha, Sam James, Florian Weimer,
autoconf, c-std-porting, Zack Weinberg, David Seifert,
Gentoo Toolchain, Paul Eggert, Frederic Berat
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
Evening,
Adam Sampson <ats@offog.org> writes:
> If the consensus on this does come down to the definition of new
> architecture triplets, are there any other changes that should (or
> could) be made at the same time, beyond time64 and LFS?
Forwarding a suggestion from Arfrever:
> Please consider making regoff_t 64-bit, on both 32-bit and 64-bit
> architectures.
> https://sourceware.org/bugzilla/show_bug.cgi?id=5945
> https://wiki.musl-libc.org/functional-differences-from-glibc.html#Regular-expressions
If an ABI break is inevitable, or a new ABI for the multilib setups,
this seems like a reasonable thing to include in it from my POV.
Have a good one.
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-14 20:26 ` Arsen Arsenović
@ 2022-11-14 20:52 ` Florian Weimer
2022-11-15 7:39 ` Arsen Arsenović
0 siblings, 1 reply; 56+ messages in thread
From: Florian Weimer @ 2022-11-14 20:52 UTC (permalink / raw)
To: Arsen Arsenović
Cc: Adam Sampson, Florian Weimer via Libc-alpha, Sam James, autoconf,
c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
Paul Eggert, Frederic Berat
* Arsen Arsenović:
> Evening,
>
> Adam Sampson <ats@offog.org> writes:
>> If the consensus on this does come down to the definition of new
>> architecture triplets, are there any other changes that should (or
>> could) be made at the same time, beyond time64 and LFS?
>
> Forwarding a suggestion from Arfrever:
>> Please consider making regoff_t 64-bit, on both 32-bit and 64-bit
>> architectures.
>> https://sourceware.org/bugzilla/show_bug.cgi?id=5945
>> https://wiki.musl-libc.org/functional-differences-from-glibc.html#Regular-expressions
>
> If an ABI break is inevitable, or a new ABI for the multilib setups,
> this seems like a reasonable thing to include in it from my POV.
Uhm, this seems to be something affecting 64-bit targets, not 32-bit
targets, after the POSIX fix went in? We have a few more such quirks.
(I understood the question to be about cleanup opportunities for 32-bit
architectures.)
Thanks,
Florian
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: On time64 and Large File Support
2022-11-14 20:52 ` Florian Weimer
@ 2022-11-15 7:39 ` Arsen Arsenović
0 siblings, 0 replies; 56+ messages in thread
From: Arsen Arsenović @ 2022-11-15 7:39 UTC (permalink / raw)
To: Florian Weimer
Cc: Adam Sampson, Florian Weimer via Libc-alpha, Sam James, autoconf,
c-std-porting, Zack Weinberg, David Seifert, Gentoo Toolchain,
Paul Eggert, Frederic Berat
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
Morning,
Florian Weimer <fweimer@redhat.com> writes:
> Uhm, this seems to be something affecting 64-bit targets, not 32-bit
> targets, after the POSIX fix went in? We have a few more such quirks.
> (I understood the question to be about cleanup opportunities for 32-bit
> architectures.)
Hmm, yes, not sure what he meant. The ABI being fine on 32-bit slipped
by me when forwarding. I'll forward any clarification.
Have a great day.
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread