Re: Proposed CHOST change for the 64bit time_t transition

[Jacob Bachmeyer <jcb62281@gmail.com>]

Arsen Arsenović wrote:
> Bruno Haible <bruno@clisp.org> writes:
>   
>> Paul Eggert wrote:
>>     
>>> I'd rather just switch, as Debian has.
>>>       
>> I'd go one step further, and not only
>>   make the ABI transition without changing the canonical triplet,
>> but also
>>   make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
>>   among their predefines.
>>     
>
> 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.

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


-- Jacob