CC : The good mpfr folks also at mpfr@xxxxxxxx
------------------ 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
<https://www.mpfr.org/mpfr-current/> 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@xxxxxxxxxxxxxxxxxx:/usr/src/sys/arch/amd64/compile/GENERIC amd64
mimas#
mimas# /usr/bin/patch --version
Patch version 2.0-12u8-NetBSD
