From: "Andreas K. Huettel" <dilfridge@gentoo.org>
To: distributions@lists.linux.dev
Subject: Re: 64-bit time_t
Date: Sun, 14 Jan 2024 00:00:59 +0100 [thread overview]
Message-ID: <24319099.EfDdHjke4D@noumea> (raw)
In-Reply-To: <2a182576-0382-45ce-a5b4-b469f154a6de@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
> In https://lore.kernel.org/distributions/6614772.670kD7asE2@nimes/
> Bruno Haible wrote:
>
> > Regarding the distro people:
> >
> > The outcome of a discussion, about a month or two ago, was AFAIU that
> > Linux/x86 and Linux/arm distros have a choice between
> > (a) enabling 64-bit time_t for all packages, thus breaking ABI
> > compatibility once and becoming year 2038 saft, or
CHOST=i686-pc-linux-gnut64
> > (b) staying with the 32-bit time_t, and announcing that their
> > distro will stop working in 2038.
CHOST=i686-pc-linux-gnu
> > An incremental or partial move to 64-bit time_t would be too expensive,
> > did the distro people say.
That's the option "pain without end" (instead of an end with pain).
> or option c)
> One less troublesome solution could be to patch glibc to redefine the
> 32-bit time_t as unsigned so that ABIs could remain compatible and at
> the same time it would support timestamps until 2106.
> Though that would break any application that uses time_t for dates
> between 1901 and 1970 (are there any?).
> Do I miss any other downsides?
ENOCRYSTALBALL - how do you find where it's needed and where not?
it was perfectly legal so far...
> option d) would be to adapt all libraries that have time_t in their API
> to have both 32-bit and 64-bit time_t variants. The former for
> compatibility with old binaries and the latter for new future-proof
> binaries. This could provide a smooth transition because not all
> 3rd-party binaries can be rebuilt.
But please please please no ugly fiddling with soname.
--
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-01-13 23:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-02 12:44 64-bit time_t Bernhard M. Wiedemann
2024-01-02 12:50 ` Neal Gompa
2024-01-02 13:20 ` Adrien Nader
2024-01-13 23:00 ` Andreas K. Huettel [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24319099.EfDdHjke4D@noumea \
--to=dilfridge@gentoo.org \
--cc=distributions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).