Re: Proposed CHOST change for the 64bit time_t transition

[Florian Weimer <fweimer@redhat.com>]

* Arsen Arsenović via Gcc:

> 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.  Just doing the
> predefine doesn't really fix anything - all the problems of not being
> able to detect whether t64 support exists still persist, with no
> mechanism to prevent mixing.

Defaulting to 64-bit time_t would also make dlsym etc. work again.  For
post-GLIBC_2.1 targets (where valid binaries are expected to use symbol
versioning) it's not absolutely required to do a soname bump, just
changing the symbol version baseline should be enough (set DEFAULT to
e.g. GLIBC_2.40 in shlib-versions).  Old binaries will use
__libc_start_main@GLIBC_2.4 or __libc_start_main@GLIBC_2.34, and fail to
load.  This could be a more source-compatible change becaue I suspect
not everyone uses LIBC_SO in <gnu/lib-names.h> to get the soname for
libc.so.

I do not have a strong opinion whether this should be done for most
32-bit targets.  Except for i386, where I think we should aim to
preserve compatibility with legacy binaries for many years to come.

All these changes have implications for LSB complinace, as people keep
reminding us:

  LoongArch glibc does not provide libutil shared object, against LSB 5.0 
  <https://sourceware.org/bugzilla/show_bug.cgi?id=31136>

But as I explained on the ticket, the way LSB is constructed, it's
surprisingly architecture-specific even in its generic parts, and 32-bit
Arm with its GLIBC_2.4 baseline won't have the required GLIBC_2.3.4
symbols (such as __chk_fail@GLIBC_2.3.4) anyway.

Thanks,
Florian