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