From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.52]) by sourceware.org (Postfix) with ESMTPS id 48F693858C83 for ; Thu, 2 Mar 2023 12:18:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 48F693858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1677759456; cv=none; d=strato.com; s=strato-dkim-0002; b=TdYIyggqqvjaiqUIiqf9V6KyAuUDrJuWIIy08sd2ADaKpKoPQhzk7DJDldFqS+/XJ3 aKWPbYginH7YHZLRIymuVBBfTXvRgMfPLfzBzqLSyo+pXvkbCO28p1ExexBXV7//oLas YxTgtnHrnRrbLHtwGFLHkX/3ndoBLKMA8gX1DZ6Ybh/KddpQWDBHG4McRqAx8p2PVjab 4Vv92FigYlYTLeS49MwIZmd+CblSOEZTpQ5OoYyA0fsl7dpHff2sL6Fa6llS+2Bn8vgJ e77zMdBMMa9dfpORQcWL/TyV4Za/WrjNVEQJYDOR4uRcKUbJrHrl0KkffCHZxVOz3Q4x Ws0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1677759456; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=sD4dobb85nTb0V9Se1/BUZzQZUvq+8vxp22j7XMatPo=; b=mHxWvz/nyNZFMpAFZ3exsYx8jeJZuTCFsLrBMYeOgirM4Mtv0zNDzwae/d5QvTlFRW BnqLsuRsvPtYZ71c30b4smfWk8KuIBXt4saoSGqx5yZq6a+IAVvnPlpsDL5rTTUOjJAg Qb9TGKZB3tY5Ja31LblQz35X518gVsytz6+2c4aMe3rrmTc7+wr48/pl6yvGsCpofhSk hosw0YwGKGBH7XhFrsH+CwFetpWZ/KWbRvSZPgKX1J48Xi2PIaufreoEEdMsLyrBm4jU c1IQFnDkjJz/XjWFyKLvBjUF1dGma2JHH4rpsvYDYIKJZlp4nvZCApnwQbsDgAapWDyb KsYA== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1677759456; 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=sD4dobb85nTb0V9Se1/BUZzQZUvq+8vxp22j7XMatPo=; b=nSXm5xjEjcS8UckIEkGJih6nn3tA8J7rxskM0qWXPJnjCka6gczRgK1RrmoshhoxGi StT7JJpmwOvknAdJltzryT9En9KDkXTZu0g1M1Fo73gjMBA3Mgkya8iMrmDq/MDM8lBZ +Vzm5S83zTCYwu44a95jnda0tx0YnI2UgTWDL60S2T3xq6SVuFDXGj5fo6mp2B0/wwBu 7BepTuaZBtju1V0BQ1nSNhLJ9xA9bE5nyu9rT+sIua+jl6MGe00/rYyXWBNjoTPrgmTe QkKuMXbzfIPK5V9XLPnXA4wJjrOZHMp32fuvRaxrv+exJe4apu0xytBB/r93fVGRk1hS L1RQ== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPD2PX4gNBNqNJ5fxkgM3kgb6BDYg==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.3.0 AUTH) with ESMTPSA id Yddb27z22CHYG9R (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 2 Mar 2023 13:17:34 +0100 (CET) From: Bruno Haible To: Paul Eggert , "Richard W.M. Jones" Cc: Daniel =?ISO-8859-1?Q?P=2E_Berrang=E9?= , Demi Marie Obenour , Eric Blake , Sam James , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , Arsen =?utf-8?B?QXJzZW5vdmnEhw==?= , dueno@redhat.com Subject: Re: On time64 and Large File Support Date: Thu, 02 Mar 2023 13:17:33 +0100 Message-ID: <4158136.ciBtUerH68@nimes> In-Reply-To: <20230302110244.GK7636@redhat.com> References: <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> <20230302110244.GK7636@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard W.M. Jones wrote: > Another way to look at this is that it's a bug in gnutls and we should > fix it only in this package It's by far not just this one package. An 'fgrep -rl time_t /usr/include' search shows a number of libraries that use time_t in their API: alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl, readline, libuuid, wxwidgets, X11, libxcb - and that's just the few that I happen to have installed. If a distro takes a package-by-package approach: - Some of these packages use Gnulib, and are thus causing trouble now or will soon. - The other packages (and there are a number of them!) will either require a manual switch to _TIME_BITS=64 or blow up in 2038. I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass rebuild is - more efficient than a package-by-package approach, - also less likely to leave out some packages by mistake. > In Fedora we have a > concept of global C/C++ flags which most C/C++ applications obey: > > $ rpm --eval '%{__global_cflags}' > -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection > > We could stick -D_TIME_BITS=64 in there and then do a mass rebuild. How do you detect if a package (by mistake or intentionally) does '#undef _TIME_BITS'? A safer solution might be to hack the compilers (gcc and clang), so that they make _TIME_BITS evaluate to 64, regardless of any '#define _TIME_BITS 32' or '#undef _TIME_BITS' in the package's source code. Bruno