Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

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.

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.

AFAIK the only reason not to do that is cosmetic - and it is ugly, but
this is for a dead platform, so I'm not too worried.

> Rationale:
>
>   * We want that a user of a distro with the new ABI can build
>     packages in the usual way:
>       - ./configure; make; make install (when using Autoconf), or
>       - make; make install  (when there is just a Makefile).
>     This *requires* that gcc and clang get patched, as indicated
>     above.
>     (Only changing Debian-specific files or variables won't do it.)
>
>   * Once this has been done, is there a need for a triplet change?
>     Not in the toolchain, and not in the packages either.
>     Needs that have been mentioned in [1][2]:
>
>       - Users would like to know in which ABI they / their distro lives.
>         This can be done through a property in /etc/os-release.
>
>       - "risks incompatibility with other distributions" [2]
>         What is the problem? Do we expect users to build binaries
>         on 32-bit distro X and try to run them on 32-bit distro Y?
>         Or do we expect binary package distributors (like Mozilla,
>         videolan.org) to do so?
>         It was my impression that this approach is doomed anyway,
>         because so many shared libraries have different major version
>         in distro X than in distro Y.

It is, many do it anyway, and what's worse, many users misguidedly
prefer it to better approaches (like the ones you mentioned).

>         And that such binary package distributors use flatpak, AppImage, etc.
>         precisely to get out of this dilemma.
>
>       - Building gcc and glibc might need some particular options.
>         Such options can be documented without requiring a new triplet.
>
> References:
> [1] https://wiki.debian.org/ReleaseGoals/64bit-time
> [2] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration

-- 
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/binutils/attachments/20240908/ff2ad97e/attachment.sig>