From: Paul Eggert <eggert@cs.ucla.edu>
To: Florian Weimer <fweimer@redhat.com>, Bruno Haible <bruno@clisp.org>
Cc: bug-gnulib@gnu.org
Subject: Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64
Date: Wed, 7 Jul 2021 14:58:17 -0700 [thread overview]
Message-ID: <f182a9a7-cb05-e2e0-70ac-24037d36cf0d@cs.ucla.edu> (raw)
In-Reply-To: <87eecabjhf.fsf@oldenburg.str.redhat.com>
On 7/7/21 1:45 AM, Florian Weimer wrote:
> Y2038 support requires recompilation. If you are able to do that, why
> not recompile for a 64-bit architecture?
Doesn't this argue against _TIME_BITS=64 in general? It seems to be
saying that one should just recompile for 64-bit, and never use
_TIME_BITS=64.
> This probably needs per-package/component work to enable dual ABI,
> similar to what glibc did for its time_t interfaces....
> I don't expect many upstreams to support this effort.
Agreed.
> Two separate i386 ports seem to require the least human
> resources to maintain.
That's a reasonable approach and if people want to do that they can,
even with the latest Gnulib and the next version of Glibc.
However, people who want to run old binaries will surely stick to the
32-bit-time_t i386 port, which means they won't use the 64-bit-time_t
i386 port. So it's not clear to me that they will cotton to this approach.
next prev parent reply other threads:[~2021-07-07 21:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 2:33 [PATCH] year2038: support glibc 2.34 _TIME_BITS=64 Paul Eggert
2021-07-02 15:32 ` Florian Weimer
2021-07-02 22:29 ` Bruno Haible
2021-07-03 2:40 ` Paul Eggert
2021-07-05 14:32 ` Florian Weimer
2021-07-05 20:14 ` Paul Eggert
2021-07-06 1:34 ` Bruno Haible
2021-07-06 22:29 ` Paul Eggert
2021-07-06 2:11 ` Bruno Haible
2021-07-07 8:45 ` Florian Weimer
2021-07-07 21:58 ` Paul Eggert [this message]
2021-07-08 5:36 ` Florian Weimer
2021-07-17 3:39 ` Paul Eggert
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
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f182a9a7-cb05-e2e0-70ac-24037d36cf0d@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=fweimer@redhat.com \
/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).