From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x33.google.com (mail-oa1-x33.google.com [IPv6:2001:4860:4864:20::33]) by sourceware.org (Postfix) with ESMTPS id 881F03858D28 for ; Thu, 26 Jan 2023 13:21:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 881F03858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-16332831ed0so2289062fac.10 for ; Thu, 26 Jan 2023 05:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hH/ny6pVeAUnyF+TSpm2Su3ENRopvWye1CFPm6RiSp0=; b=qYYm0uwGnpMvVsLGvM/K4TCoBQffh3L/m9D7kWop2TKDm7emobZG02OfzDqzpyo0sJ xEdQm3pL/xMIizGJkrvAbvPqJJZYQyXUL28dA5W1OPN/puZimNOokwMNYq34XBDnGNrw 43zBouxsgkKs5BwZJJ5OtB9pGHLcEkN2PH07xh9iU7PS/tblwzwtHyTUFGH6s8N0yrfF oKpGsJ2y1WbChRBSyojyZrH9/MXh5ys419erkLAS0gc0lrFYyBT2Er15nLjA0YGrZnIJ 6X2glAc2wJv+OgT+ZfMyVIdBxHppoEFPgizDi11oldsbZ+4owGVoEAJlDUHaPO3lYeMB n6Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hH/ny6pVeAUnyF+TSpm2Su3ENRopvWye1CFPm6RiSp0=; b=XhuMSD+ZteDIkcvUzKuIWL/wQDMjxpcO2Ll9QP1eN9hD/M+NLvyS3rEbjP/iK/Hwyl mXnmYNAhhoYkXC1CyaCg7Dy3nJxX7d0EFbhe8SoL5aYvb2d4NiEgfx2kjbuCHSalETeX eSOMmadX/xXHNg1sa+nVyjrdUxXaBJNgUvi6yt8tsPN0bjx7qVXAPLz+pTuO6ekHPGg+ Lg7bYb/TJtG6b7oFz9xvbDB00KSxzLi4qzCL9bqTNWfZEZ30WXsrYcJAD59VWH6biSUC 8KsaRwTbxz7O9qterGWgZZydWqYbA2hpELygJfbIGKpjCnyGP24Cmsj7PqpicZ0MirYN B52w== X-Gm-Message-State: AFqh2kqhvt/V8U/ZVhKtvQ4XZG8YWU/EFp1gbyE/F+PNaTb5yaUU2PS8 TfPmOWpPxAzQw9zMRRwr7Ne7vXRTPeybxuvH+Mg= X-Google-Smtp-Source: AMrXdXsYQNT9PKoCdcntlz5OSrw6j2CukJMcS+qOv0veVGmIZ9sSP8bKGpPUMJq7j8e1GjfEbIM9qQ== X-Received: by 2002:a05:6871:4484:b0:14f:24f2:21c2 with SMTP id ne4-20020a056871448400b0014f24f221c2mr18166147oab.55.1674739273792; Thu, 26 Jan 2023 05:21:13 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c1:7e99:6983:51e0:457e:734? ([2804:1b3:a7c1:7e99:6983:51e0:457e:734]) by smtp.gmail.com with ESMTPSA id j1-20020a4aa641000000b0049bfbf7c5a8sm500684oom.38.2023.01.26.05.21.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Jan 2023 05:21:12 -0800 (PST) Message-ID: <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> Date: Thu, 26 Jan 2023 10:21:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries Content-Language: en-US To: libc-alpha@sourceware.org References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On 26/01/23 01:13, Paul Eggert wrote: > On 1/25/23 15:59, Andreas K. Huettel via Libc-alpha wrote: > >> This was discussed already in the previous thread on this list [1], with reactions >> ranging from "need new triplet" via "need new libdir" to "meh".... >> [1] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html > > One thing new since that November email is that in bleeding-edge Autoconf we've scaled back AC_SYS_LARGEFILE so it no longer widens time_t by default. Instead, you need to pass a new option --enable-year2038 to 'configure' if you want 64-bit time_t on 32-bit glibc x86 and ARM platforms, which as I understand it are the only platforms that have this problem. If a package author wants --enable-year2038 to be the default, they need to use Autoconf's new AC_SYS_YEAR2038 macro. This change has also percolated into Gnulib so source packages using recent Gnulib will need to use the new Gnulib module year2038 if they want --enable-year2038 to be the default. > > This change was done out of concern that although AC_SYS_LARGEFILE has long tweaked blkcnt_t, dev_t, ino_t, fsblkcnt_t, fsfilcnt_t and rlim_t (in addition to off_t of course), having it also tweak time_t was a compatibility bridge too far. > >> Proposal: glibc gains two new build-time configure options: >> * --enable-hard-time64 >> * --enable-hard-lfs > > This sort of thing sounds like a good way to go. However, I suggest simplifying things, by having just one option (say, --enable-hard-sys-types64) that does both at once, because --enable-hard-time64 and --enable-hard-lfs would not be orthogonal and this would be confusing, and anyway nobody sane will want to use one option without also using the other - who wants the agony of *two* conversions? I agree a single option make sense, there is no good reason to add LFS-only with 64-bit support. It also simplify build systems that are not autoconf based. A minor problem, which is for all configure switch, it adds another build permutation that incur in more testing requirements and maintenance. However it does not help with the rest of plumbing that a system will need to do for correct set library selection, since ldconfig will see both 32 and 64 bit time_t shared library essentially being the same ABI. A mixed environment with legacy binaries/libraries will still incur in similar issue, albeit in a different direction. So to run old binaries one will need to either setup LD_PRELOAD/LD_LIBRARY_PATH/RUNPATH or run it in an isolated environment (which itself has its own issues). And the configure switch also adds a kind of fragmentation, but it is also we already have when a projects enables time64_t anyway. So although I am not quite against --enable-hard-sys-types64, I personally think we should do something more drastically (which not all other glibc developers agree) and flip the switch to enable 64-bit time_t *as default* and document 32-bit is opt-in. If Fedora or any distro wants to keep the *broken* non-LFS / 32 bit time_t, it is up to them to patch glibc to do so.