Re: Accelerating Y2038 glibc fixes

[Rich Felker <dalias@libc.org>]

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...

> > 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.

Rich