From: Lukasz Majewski <lukma@denx.de>
To: Rich Felker <dalias@libc.org>
Cc: Arnd Bergmann <arnd@arndb.de>, Wolfgang Denk <wd@denx.de>,
Florian Weimer <fweimer@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>,
Joseph Myers <joseph@codesourcery.com>
Subject: Re: Accelerating Y2038 glibc fixes
Date: Thu, 18 Jul 2019 09:20:48 +0200 [thread overview]
Message-ID: <20190718092048.63b90db1@jawa> (raw)
In-Reply-To: <20190717223706.GO1506@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]
Hi Rich,
> On Wed, Jul 17, 2019 at 11:57:48PM +0200, Lukasz Majewski wrote:
> > > As a result, I'm leaning strongly towards a conclusion that a
> > > solution that doesn't split the two cases is better, and it's
> > > probably what we'll do for musl.
> >
> > The approach would be very similar to what was done with
> > _FILE_OFFSET_BITS==64. The end user would need to add
> > -D_TIME_BITS==64 when compiling programs against glibc on 32 bit
> > architecture.
>
> Yes, except that I'd switch the default from the beginning. glibc made
> the mistake of not doing this with _FILE_OFFSET_BITS, and it's still
> the wrong default 20 years later, with every application's build
> system containing workarounds...
>
> > > It's a viable solution for users to run new
> > > 32-bit stuff alongside a 32-bit glibc target that's being
> > > phased-out and nearing EOL, but if this is the only option I
> > > think it would just lead to distros dropping the targets.
> > >
> > > > Any of the above approaches (including the current plan of
> > > > supporting time32 and time64 in a single glibc binary) can of
> > > > coexist, but the more incompatible approaches get implemented,
> > > > the more fragmentation of ABIs we get.
> > >
> > > I'm moderately in favor of supporting both in a single binary. As
> > > noted elsewhere, this fundamentally does not break ABI between
> > > libc consumers (main apps or 3rd party libs) and libc, only
> > > between pairs of libc consumers that have used the affected types
> > > as part of their public interfaces.
> >
> > As I've written above. For the end user it shall be enough to add
> > -D_TIME_BITS==64 during compilation.
>
> I think you missed the whole thing about ABI between pairs of libc
> consumers...
You are probably right, as I'm now biased to the systems where the
Y2038 safe BSP is build with OE/Yocto and deployed (the "self containing
release").
Thanks for extra explanation.
>
> > > To answer Wolfgang Denk's original question, in my opinion, the
> > > single most valuable thing for accelerating the time64 process
> > > that third parties could contribute is detailed analysis of the
> > > interfaces that will break.
> >
> > Such analysis is already done and available on glib'c wiki page
> > [3].
>
> ...because there's no such analysis here. Such analysis is basically a
> grep -r of /usr/include on a Debian system with *-dev installed,
> combined with some automated analysis of what packages depend on each
> matching package's library, then manual analysis to determine impact
> (and in many cases, whether the lib is even a real lib that's used by
> multiple programs rather than just by the program it ships with).
>
> Arnd sent me a really preliminary grep like this a couple weeks ago,
> but doing it right is going to take a lot more time.
Is this script available somewhere? I'm wondering if I could adapt it
(and run) to meta-y2038?
>
> Rich
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-18 7:20 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 7:21 Accelerating Y2038 glibc fixes Wolfgang Denk
2019-07-16 9:32 ` Wolfgang Denk
2019-07-16 11:50 ` Siddhesh Poyarekar
2019-07-16 12:40 ` Wolfgang Denk
2019-07-16 12:44 ` Florian Weimer
2019-07-16 14:52 ` Wolfgang Denk
2019-07-16 15:09 ` Florian Weimer
2019-07-16 15:19 ` Andrew Pinski
2019-07-17 14:15 ` Arnd Bergmann
2019-07-17 14:41 ` Florian Weimer
2019-07-17 16:00 ` Wolfgang Denk
2019-07-17 16:04 ` Florian Weimer
2019-07-17 16:18 ` Lukasz Majewski
2019-07-18 18:53 ` Adhemerval Zanella
2019-07-18 19:13 ` Florian Weimer
2019-07-18 20:31 ` Adhemerval Zanella
2019-07-18 21:20 ` Florian Weimer
2019-07-18 22:32 ` Paul Eggert
2019-07-19 7:21 ` Andreas Schwab
2019-07-19 3:06 ` Rich Felker
2019-07-19 17:44 ` Adhemerval Zanella
2019-07-19 19:03 ` Alistair Francis
2019-07-25 20:40 ` Joseph Myers
2019-07-29 17:47 ` Adhemerval Zanella
2019-07-29 19:58 ` Joseph Myers
2019-07-29 21:00 ` Adhemerval Zanella
2019-07-29 21:08 ` Joseph Myers
2019-07-29 23:12 ` Paul Eggert
2019-07-29 23:30 ` Joseph Myers
2019-07-17 17:50 ` Rich Felker
2019-07-17 21:57 ` Lukasz Majewski
2019-07-17 22:37 ` Rich Felker
2019-07-18 7:20 ` Lukasz Majewski [this message]
2019-07-18 13:35 ` Rich Felker
2019-07-18 14:47 ` Rich Felker
2019-07-18 14:49 ` Florian Weimer
2019-07-18 15:46 ` Rich Felker
2019-07-18 16:43 ` Adhemerval Zanella
2019-07-20 4:43 ` Rich Felker
2019-07-25 19:54 ` Joseph Myers
2019-07-26 10:39 ` Lukasz Majewski
2019-07-29 18:55 ` Zack Weinberg
2019-07-29 20:12 ` Joseph Myers
2019-07-30 11:02 ` Lukasz Majewski
2019-07-30 12:24 ` Joseph Myers
2019-07-30 14:04 ` Lukasz Majewski
2019-08-09 7:25 ` Lukasz Majewski
[not found] ` <CAKCAbMhOMQ9yTFpy+OQkDvZPPFf_fFn6oSxjvLTaUwC4jpPRag@mail.gmail.com>
2019-08-09 12:32 ` Fwd: " Zack Weinberg
2019-07-30 19:58 ` Joseph Myers
2019-07-30 20:28 ` Florian Weimer
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://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190718092048.63b90db1@jawa \
--to=lukma@denx.de \
--cc=arnd@arndb.de \
--cc=dalias@libc.org \
--cc=fweimer@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=wd@denx.de \
/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).