From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) by sourceware.org (Postfix) with ESMTPS id 4B7A03858C33 for ; Wed, 24 Aug 2022 16:52:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B7A03858C33 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=blastwave.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=blastwave.org X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-oetec-MailScanner-From: dclarke@blastwave.org X-oetec-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.11, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, DKIM_VALID_EF -0.10, NICE_REPLY_A -0.00, T_SCC_BODY_TEXT_LINE -0.01, URIBL_BLOCKED 0.00) X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-ID: 27OGpxL0007169 X-oetec-MailScanner-Information: Please contact oetec for more information Received: from [172.16.35.2] (cpeac202e7325b3-cmac202e7325b0.cpe.net.cable.rogers.com [99.253.170.241]) (authenticated bits=0) by mail.oetec.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 27OGpxL0007169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 24 Aug 2022 12:52:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blastwave.org; s=default; t=1661359921; bh=LeJK9xI7P/Ez+tI5tbMDXbBO6ZSgD3SlINGpemHKbcU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=WiBD84Pc1VQjcuHkGXAYSVlk+VOQxs8k81wcC5H9pxy7P4RqMJ2Q3rvwDQLWvK4Tq 3m3gxSolxtSlQ5DTX/BxCJIcOcLkzHcYSu99USI/bz9DLFnmWLa08LG1tC8skwf66C 0LtMSFiJYmHgHrJyokMnqxei4CyFgt7TFHvdyOQc7EuQPGGD/Fst0g6IxdHmLoVi+H u11IutG+TbOMR086aXyHdKcyOokU1V2ZIM4sKMk00i9+uKU3tXgZ+35bPLiVWEsMmA DSfewzv27e+iP0SxB+haIJEJgddmGkqChQtHvZQPNaP9I2kes1SC3map81bbtCL9nl BVoB6YsTYajAw== Message-ID: Date: Wed, 24 Aug 2022 12:51:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: one of those annoying little things Content-Language: en-US To: "Matthew R. Wilson" Cc: gcc-help@gcc.gnu.org, mpfr@inria.fr References: <49c6528e-13d9-fcff-2046-6a0a167c3fea@blastwave.org> <20220824082743.3jqs3owseaulpjh7@mattwilson.org> From: Dennis Clarke In-Reply-To: <20220824082743.3jqs3owseaulpjh7@mattwilson.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: CC : The good mpfr folks also at mpfr@inria.fr ------------------ From the GCC Help Maillist ------------------ On 8/24/22 04:27, Matthew R. Wilson wrote: > Hi Dennis and Xi, > > On 08.24.2022 13:20, Xi Ruoyao via Gcc-help wrote: >> On Wed, 2022-08-24 at 00:21 -0400, Dennis Clarke via Gcc-help wrote: >>>      Not sure who else have been doing bootstraps on machines wherein >>> the >>> common sense thing to do is protect the source tree. What I mean is that >>> I extract the gcc 12.2.0 tarball of joy as the root user. >>> >>> mkdir: .am388: Permission denied >>> ../../../gcc-12.2.0/mpfr/doc/mpfr.info: Permission denied >> >>> Turns out, wild, but that directory for the mpfr doc stuff has files >>> that no user has rights to other than root. That has to be a bug right? >>> Could be the mpfr guys but hey this seems weird. >> >> In MPFR Makefile.in there is: >> >> $(srcdir)/mpfr.info: mpfr.texi $(mpfr_TEXINFOS) >> >> and >> >> mpfr_TEXINFOS = texinfo.tex fdl.texi >> >> So mpfr.info is only regenerated if it does not exist, or its timestamp >> is older than mpfr.texi, texinfo.tex, or fdl.texi.  This should not >> happen if you extract mpfr from a release tarball, where: >> >> 2019-01-07 21:49 fdl.texi >> 2020-07-10 19:59 mpfr.info >> 2020-07-10 19:52 mpfr.texi >> 2020-04-14 19:12 texinfo.tex >> >> We can see mpfr.info is already up-to-date so make should not regenerate >> it. >> >> Maybe your patch changed mpfr.texi (you forgot to add the URL of "[1]" >> so I cannot know :), or you've messed up the timestamp of those files >> somehow (one notable case: using "cp -r" to copy the MPFR source tree >> can reset the timestamps to current system time). > > I suspect this is indeed the case. > Good day and thank you good folks for the thoughtful reply. Indeed yes I forgot the footnote for the patch : https://www.mpfr.org/mpfr-current/#download This has long been a topic of debate with the various gcc folks who claim to never use anything other than the specified prerequisites[1] and do not apply a patch or anything else. Strangely I get really good results from my bootstrap experiments and certainly no worse than a lot of other folks running continuous non-stop testing on the trunk code stuff. Where, quite frankly, those tests don't mean much to me unless it is an actual release. Regardless we have this problem on NetBSD and I think I see the issue after reading all your good thoughts. > The instructions on the MPFR patch download page > for the cumulative patch against > the 4.1.0 release explicitly tell you to use the following patch > command: > > patch -N -Z -p1 < path_to_patches_file Yes, I see that and also the words : The -Z option sets the modification time of the patched files from time stamps given in the patch file, thus avoiding the need of some development utilities (such as autoconf); this may generate a "Not setting time" warning for the PATCHES file, but you can safely ignore it. Really? Can I safely ignore it? Because NetBSD has no such option for the patch command therein. Looking more closely into the MPFR patch we see that indeed yes some files were changed and the timestamps also. Let me demonstrate : * * * step 1 - extract the mpfr sources * * * Last login: Tue Aug 23 00:26:06 2022 from 172.16.35.2 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 Welcome to NetBSD! mimas$ mkdir mpfr_patch_test mimas$ cd mpfr_patch_test mimas$ ls /opt/bw/src/mpfr* /opt/bw/src/mpfr-4.1.0.patch /opt/bw/src/mpfr-4.1.0.tar.gz mimas$ gzip -dc /opt/bw/src/mpfr-4.1.0.tar.gz | tar -xf - mimas$ cd mpfr-4.1.0/doc mimas$ ls -l total 2024 -rw-r--r-- 1 dclarke devl 18224 Jan 8 2020 FAQ.html -rw-r--r-- 1 dclarke devl 855 Jan 8 2020 Makefile.am -rw-r--r-- 1 dclarke devl 25958 Jul 10 2020 Makefile.in -rw-r--r-- 1 dclarke devl 77859 Jul 10 2020 README.dev -rwxr-xr-x 1 dclarke devl 1496 Jan 8 2020 check-typography -rw-r--r-- 1 dclarke devl 21161 Jan 7 2019 fdl.texi -rw-r--r-- 1 dclarke devl 2713 Jun 11 2020 mini-gmp -rw-r--r-- 1 dclarke devl 271747 Jul 10 2020 mpfr.info -rw-r--r-- 1 dclarke devl 216914 Jul 10 2020 mpfr.texi -rw-r--r-- 1 dclarke devl 376807 Apr 14 2020 texinfo.tex mimas$ cd .. mimas$ * * * step 2 - apply the patch * * * mimas$ mimas$ patch -N -b -p1 -i /opt/bw/src/mpfr-4.1.0.patch > ../mpfr_patch.log 2>&1 mimas$ * * * step 3 - check that the patch was applied correctly Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -Naurd mpfr-4.1.0-a/doc/mpfr.info mpfr-4.1.0-b/doc/mpfr.info |--- mpfr-4.1.0-a/doc/mpfr.info 2020-07-10 11:59:13.000000000 +0000 |+++ mpfr-4.1.0-b/doc/mpfr.info 2021-03-09 13:55:51.167071327 +0000 -------------------------- Patching file doc/mpfr.info using Plan A... Hunk #1 succeeded at 3217. No such line 4578 in input file, ignoring Hunk #2 failed at 4583. Hunk #3 failed at 5169. 2 out of 3 hunks failed--saving rejects to doc/mpfr.info.rej So there we see the failure. In the doc directory I see : mimas$ ls -lapb doc total 2912 drwxr-xr-x 2 dclarke devl 512 Aug 24 16:42 ./ drwxr-xr-x 9 dclarke devl 1024 Aug 24 16:43 ../ -rw-r--r-- 1 dclarke devl 18224 Jan 8 2020 FAQ.html -rw-r--r-- 1 dclarke devl 855 Jan 8 2020 Makefile.am -rw-r--r-- 1 dclarke devl 25958 Jul 10 2020 Makefile.in -rw-r--r-- 1 dclarke devl 77859 Jul 10 2020 README.dev -rwxr-xr-x 1 dclarke devl 1496 Jan 8 2020 check-typography -rw-r--r-- 1 dclarke devl 21161 Jan 7 2019 fdl.texi -rw-r--r-- 1 dclarke devl 2713 Jun 11 2020 mini-gmp -rw-r--r-- 1 dclarke devl 217506 Aug 24 16:42 mpfr.info -rw-r--r-- 1 dclarke devl 271747 Jul 10 2020 mpfr.info.orig -rw-r--r-- 1 dclarke devl 2484 Aug 24 16:42 mpfr.info.rej -rw-r--r-- 1 dclarke devl 217300 Aug 24 16:42 mpfr.texi -rw-r--r-- 1 dclarke devl 216914 Jul 10 2020 mpfr.texi.orig -rw-r--r-- 1 dclarke devl 376807 Apr 14 2020 texinfo.tex > The -Z is what's critical here: it sets the timestamps of the patched > files to the timestamps included in the patch itself. > Seems that we can not safely ignore that option. Perhaps the failure here is with the "patch" software in NetBSD? Maybe GNU patch is what is needed to get that -Z option? > The cumulative patch indeed patches mpfr.info and mpfr.texi; with the > correct timestamps, the patch maintains the correct sequencing of these > files so that it's a "clean" source tree that doesn't require the > documentation to be regenerated (since the patch includes the > regenerated .info output file that corresponds to the patches to the > .texi files). > > If you patch without the -Z, I'm guessing you hit the condition in the > MPFR makefile that thinks you need to regenerate the documentation in > the source tree. > Yep, that must be the issue here. > I have prepared a write-protected GCC source tree on a Solaris > 11.4/SPARC system using the following steps, and I was then able to > perform an out-of-tree build as an unprivileged user without > encountering any permissions problems: > > As root: # mkdir -p /export/build/gcc > # cd /export/build/gcc > # curl -LO ftp://ftp.gnu.org/gnu/gcc/gcc-12.2.0/gcc-12.2.0.tar.gz > # curl -LO https://www.mpfr.org/mpfr-current/allpatches > # gtar xzf gcc-12.2.0.tar.gz > # cd gcc-12.2.0 > # ./contrib/download_prerequisites # cd mpfr # patch -N -Z -p1 < > ../../allpatches > # cd ../.. # chown -R root:root gcc-12.2.0 > # chmod -R -w gcc-12.2.0 > I am also doing something similar on Fujitsu SPARC64 with Solaris 11.3 but I suspect no real problems will happen because I have GNU patch there : spartacus$ which patch /usr/xpg4/bin/patch spartacus$ spartacus$ which gpatch /bin/gpatch In any case it looks like the "you can safely ignore it" may only be mostly harmless. Mostly. As a final note the bootstrap on my NetBSD machine is well into stage4 now and I suspect that the stage3 and stage4 results will be a perfect binary match to each other. At least I hope. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional [1] https://gcc.gnu.org/pipermail/gcc-help/2022-August/141848.html [2] mimas# uname -a NetBSD mimas.genunix.com 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 mimas# mimas# /usr/bin/patch --version Patch version 2.0-12u8-NetBSD