From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 571641F461 for ; Wed, 17 Jul 2019 22:37:18 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=XZsm 2ZXO2MseEV/Lil7RRz1cZqgg4s+nlZgFI7104torLJZJWT5QnuwEY8wWUCn0DOxc vPW7QrENUqYQIhwRWFdCTCUABlTccVzTnQA8OGu8s1HQI8QRGSFy1cNEIw3t1AMD /L1q7z0N/mNge9QNqmFn8AHLKDOSNp9v+Yunsjw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=HZHVHVjvlo GPhTGF7Q8K+e1OF34=; b=LiROjlOt1B8VQliqAZmtlv37V58duxINDyv4OfEdgI UhfWuZsTLhEIghpwS+a+xVB1s0osQfmnzZHWPcN8mQIAdlUqVy9bjjcqmfXI8hO2 1uwdjcEY4qNsjxmmRlIR+tmVdjhdYqJ8nUopilg460k9phYnVNJRvQImAfW5jnEf g= Received: (qmail 72370 invoked by alias); 17 Jul 2019 22:37:16 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 72361 invoked by uid 89); 17 Jul 2019 22:37:16 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Date: Wed, 17 Jul 2019 18:37:06 -0400 From: Rich Felker To: Lukasz Majewski Cc: Arnd Bergmann , Wolfgang Denk , Florian Weimer , GNU C Library , Joseph Myers Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <20190717223706.GO1506@brightrain.aerifal.cx> References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <20190717175026.GM1506@brightrain.aerifal.cx> <20190717235748.2552834a@jawa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190717235748.2552834a@jawa> User-Agent: Mutt/1.5.21 (2010-09-15) 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