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: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 6FAAB1F8C6 for ; Fri, 2 Jul 2021 22:30:18 +0000 (UTC) Received: from localhost ([::1]:60516 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lzRfs-00077V-WE for normalperson@yhbt.net; Fri, 02 Jul 2021 18:30:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49278) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lzRfq-00076w-49 for bug-gnulib@gnu.org; Fri, 02 Jul 2021 18:30:14 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.217]:12054) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lzRfm-0000zY-69 for bug-gnulib@gnu.org; Fri, 02 Jul 2021 18:30:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1625264994; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=PFSuVD0EHO6n6T14T7y3gzeB+L5yuiswYlNykJqmXRk=; b=JXp4yUuN18mil3YdWMaBaElSufhrMfZQKDkscrPUdIX24tXBgnQo/6HHDL8BkmrNjf Ur6l9BCBUgmqeJs560VrYGSpwJecnP29+WWaDWHJyXngQXrhiWuslFAqEqIstCynXy2a 4KQo1jAOrEsEl7PnW5jZrwbFcL+OZeNQqOPGQ5Q2gHKxro0EKJTLaOQT3qy6gWjt6pzc rKWafKMahJ+ZH3pWfsl4mRtAgm/LrZqvK+jYncQOp4DH10YEYj8rORPuHv6MU8XvsDWI YH9vAwC8MKnE/baXMucdyi5eoO88Qc15BiZXtpFuB6yrGqXTXrYbcpZY4rEPlSbBHutE zWjw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGKf9yfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.28.1 DYNA|AUTH) with ESMTPSA id e088a2x62MTrFIx (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Sat, 3 Jul 2021 00:29:53 +0200 (CEST) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64 Date: Sat, 03 Jul 2021 00:29:52 +0200 Message-ID: <4302797.ikRTjI96fm@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <878s2ozq70.fsf@oldenburg.str.redhat.com> References: <20210702023332.2482490-1-eggert@cs.ucla.edu> <878s2ozq70.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Received-SPF: none client-ip=81.169.146.217; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Paul Eggert Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Florian, > > In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit, > > defining _FILE_OFFSET_BITS=3D64 and _TIME_BITS=3D64 makes time_t 64-bit. > > Apps must define both macros. Gnulib applications that use either > > the largefile or the year2038 modules will want this behavior; > > largefile because it deals with the off_t and ino_t components of > > struct stat already, and so should also deal with time_t. >=20 > Won't this be a very disruptive change to distributions, whose system > libraries have not switched to 64-bit time_t on 32-bit? >=20 > gnulib should not try to force a different distribution default. I'm > worried that this will lead to distributions abandoning 32-bit i386 > support altogether because the support cost is too high=E2=80=94and you c= an't > even run legacy binaries anymore. I don't understand your points regarding "very disruptive change", "distribution default", and "can't even run legacy binaries". Probably you have something in mind that differs from my understanding. In my understanding, a change like this one propagates to the tarballs that make use of Gnulib. For example, GNU tar will, starting with the next version, contain logic that has the effect of adding #define _TIME_BITS 64 to the config.h of that package. Thus, GNU tar and GNU mt will, on glibc =E2=89=A5 2.34 systems, be internally using a different time_t type t= han programs that don't use Gnulib (e.g. util-linux) and programs that use older versions of Gnulib (e.g. GNU clisp). =46rom the perspective of the distributions, this is a no-op, IMO. The only problem that I see is with *libraries* that have an API that references the time_t type. It is well-known that when a library - references off_t or 'struct stat' in its API, and - was built with AC_SYS_LARGEFILE in effect, the packages that use this library also have to be built with AC_SYS_LARGEFILE. This has caused problems in the past, when _FILE_OFFSET_BITS=3D64 was introduced (ca. 2000-2005). Now, Paul's change has the effect that when a library - references time_t in its API, and - either it was built with Gnulib module 'largefile', or it was built without -D_TIME_BITS=3D64 but the package that uses it is built with Gnulib module 'largefile' or -D_TIME_BITS=3D64, there will be similar problems. Are there many such libraries? Not many, but come important ones. A quick look in my /usr/include lists libcurl glib, gtk gdbm gnutls, openssl libpng wxWidgets X11/Xos_r.h Also, there might be problems with socket/pipe protocols which transfer time_t values within a stream of data. Which such protocols exist? I don't see big problems with distribution vendors, since 56% of the distributions have already abandoned i386 ports by now [1], and more will follow suit. The rest of the distros can easily add -D_TIME_BITS=3D64 to their common compilation flags. However, I do see some bug reports coming from people who still use such old i386 distros and try to build packages that rely on libraries that use time_t in their APIs. What is the best approach? - A package-by-package approach that allows each package maintainer to choose their preference? That would mean, to keep 'largefile' and 'year2038' as independent modules. - Or a global approach, like Paul's patch does? =46rom the times _FILE_OFFSET_BITS was introduced, I remember that the package-by-package approach led to major trouble, and that the global approach =E2=80=94 use -D_FILE_OFFSET_BITS=3D64 in all compilations = =E2=80=94 was ultimately the simplest way forward. Bruno [1] https://distrowatch.com/search.php#advanced