Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

>> At that point, we should bump SONAME of libc and simply remove 32-bit
>> time support.  This would probably be okay generally.
>
> This is probably the best solution to this problem at hand, especially since
> the old ABI has a definite expiration date about 14 years from now.  Bump the
> libc SONAME major and hope that we can get rid of the last dependencies on the
> old SONAME before the deadline.  We will have 14 years to do it, if that arch
> is even still used then.

Indeed.  I believe the current thinking is that the existing software
for the old ABI could benefit from libc updates, hence not breaking it,
but.. it practically is somewhat broken already (hence the troubles that
lead to this thread).

>> [...]
>> But, in the case we don't do a bump, why not update the tuple?  This'd
>> allow easy communication of whether we have 32 bit time to all
>> components of the system, and, in lieu of a better detection mechanism,
>> it'd allow anyone at a glance to look at a hosts tuple and see whether
>> it is compatible with something based on the tuple it was built on.
>>   
>
> This is closely related to the idea I floated a year ago of redefining
> configuration tuples as lists of tags (with a canonical order) progressively
> narrowing a broad architecture.  Start with CPU architecture and work
> "narrower" from there.  In that system, adding "-t32" and "-t64" to indicate
> time_t width would be the simple solution.  In context then, it was to handle
> different libc choices on Windows.

Yes, that's about what I imagined as the effect of the suffix.
-- 
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 381 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240910/3217fcb6/attachment.sig>