Accelerating Y2038 glibc fixes

[Lukasz Majewski]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20190718/01517332/attachment.sig>