From: Florian Weimer <fweimer@redhat.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
Elmar Stellnberger <estellnb@elstel.org>,
libc-maintainers@gnu.org, libc-alpha@sourceware.org
Subject: Re: time64 functions for glibc
Date: Mon, 31 May 2021 21:16:59 +0200 [thread overview]
Message-ID: <87a6oa90ic.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <f3e8926f-b451-e10f-7d26-2970775ec131@linaro.org> (Adhemerval Zanella's message of "Mon, 31 May 2021 16:08:24 -0300")
* Adhemerval Zanella:
> We either make it default for all affected architectures or we should
> keep as is, I see not point in making it architecture dependent.
I'm under the impression that 32-bit Arm is sufficiently different.
> And I don't see your point here: if the legacy is being recompiled
> it is in essence not in compatibility mode. We really need to move
> from non-LFS and 32-bit time_t interfaces.
It's about providing a stack of 32-bit libraries for use by legacy
applications. These libraries are rebuilt from time to time by
distributions and would pick up the changed default, therefore becoming
incompatible with legacy applications. Development work is required to
support both ABIs in one installation. If no one is willing to do the
work (which is what I expect for most of the relevant libraries), for
i386 the more useful choice is the current ABI, to support legacy
applications that can't be recompiled.
Thanks,
Florian
next prev parent reply other threads:[~2021-05-31 19:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-31 15:43 Elmar Stellnberger
2021-05-31 15:51 ` Paul Zimmermann
2021-05-31 16:01 ` Adhemerval Zanella
2021-05-31 18:46 ` Paul Eggert
2021-05-31 18:56 ` Florian Weimer
2021-05-31 19:08 ` Adhemerval Zanella
2021-05-31 19:16 ` Florian Weimer [this message]
2021-05-31 19:28 ` Adhemerval Zanella
2021-06-01 16:32 ` Elmar Stellnberger
2021-05-31 19:03 ` Adhemerval Zanella
2021-06-22 21:41 ` Paul Eggert
2021-06-23 13:29 ` Adhemerval Zanella
2021-06-23 16:59 ` Joseph Myers
2021-06-23 17:59 ` Paul Eggert
2021-06-24 17:37 ` Joseph Myers
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=87a6oa90ic.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=eggert@cs.ucla.edu \
--cc=estellnb@elstel.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-maintainers@gnu.org \
/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).