Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

Paul Eggert <eggert@cs.ucla.edu> writes:

> One possible improvement would be to append "t32" if you want 32-bit time_t,
> instead of appending "t64" for 64-bit time_t. That way, people wouldn't be
> stuck with appending that confusing "t64" for the foreseeable future, and only
> specialists concerned with 32-bit time_t would need to know about the issue.

But that'd change semantics in non-obvious ways.  The intention behind
this suggestion is to have a mechanism to communicate to packages and
the toolchain alike that "yes, this system is Y2038-proof".  There is
currently no mechanism to do that.  There isn't even a mechanism to
guess based on your dependencies whether you should also enable LFS and
T64 (and there can't be a general one - you'd need to detect what
libraries are doing what if they have time_t or other system integers on
ABI boundaries, which is not generally possible).  Not that the latter
would suffice - even if we changed all packages we can to use such a
mechanism, there would be plenty of packages that don't (think of all
the hand-rolled makefiles..).

An alternative that I pondered was to teach the linker about some notion
of "compatibility strings" that it would compare and reject if
different, plus teaching the compiler how to emit those, plus teaching
glibc to tell the compiler to emit those..  We could have key-value
pairs in some section.  For each key K, we could have the linker check
that, for each (shared or otherwise) object either does not contain K or
contains K with the same value as all the other ones, and produce an
error otherwise.  On the resulting object, the KV pairs would be the
union of all KV pairs of all constituent objects.

... but this is for i?86, a CPU family I haven't used in ~15 years (and
I suspect many also have not..), and there are other things eating my
time.  And it'd still require a world rebuild.

> Personally, I hope backward-compatibility concerns don't require this sort of
> thing. I'd rather just switch, as Debian has.

The "status quo" of some packages enabling it of their own volition, and
some not, leads to various subtle breakages (example:
https://bugs.gentoo.org/828001).  I think switching like that would not
be much different.

I do not know what approach Debian took, but if it is one of altering
the toolchain, then this is a sure way to introduce subtle divergences
between distros (this is why I've suggested we CC the GCC and binutils
MLs); if it is one of teaching debhelper (is that the right tool?  not
sure) about it, then this will break user-compiled packages (so,
./configure && make && make install, or moral equivalent).  If it is to
alter libc, then, can we do libc.so.7?  ;)

The only actually solid approach I see today is to /somehow/ communicate
to the system to not use 32-bit time, ever (and consequently, to enable
LFS).  I think that the "least effort" path to do that is through the
tuple.

There's precedent for this also, AFAIK, in the 32-bit ARM world
(gnueabi/gnueabihf, whatever that means).

config.guess would need to be altered a little bit.  My preference is
for [[ $os = *-*-gnu*t64* ]] informing glibc to completely ignore
_FILE_OFFSET_BITS, _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, and
_TIME_BITS and just presume 64 for all of those system integers.  This
means that config.guess could undef those (in case a toolchain sets
those) and include some libc file, then check for sizeof (time_t), or
just have glibc define something if on a gnut64 target.

> I felt the same way about the 64-bit off_t back in the 1990s. It was obvious 
> to
> me even at the time that we would have been significantly better off making
> off_t 64-bit, while keeping 32-bit off_t in the ABI for backward 
> compatibility;
> this is what NetBSD did with time_t in 2012. Although I realize others felt
> differently, I never fully understood their concerns.

That is history now I fear; I also wish that time_t was made
64-bit a long ago ;)

> And here I am, three decades later, still having to make changes[1] to
> Autoconf's AC_SYS_LARGEFILE macro to continue to support that 30-year-old 
> off_t3
> mistake, and now with 64-bit time_t interacting with 64-off_t in 
> non-orthogonal
> ways.

Indeed, and the "best" part is that, whatever you do in autoconf, unless
a program exists in isolation only interfacing with libc, it will break
some consumer (or will be broken by some dependency) because there's no
mechanism to signal the time_t size across ABI boundaries.
-- 
Arsen Arsenović

signature.asc
Description: PGP signature