Dear ALL : 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. Then inside that directory structure I crack out the gmp/mpfr/mpc goodness and even apply the correct patch for mpfr[1]. So anyways, funny thing happens when I try to build out of tree : . . . config.status: creating tools/bench/Makefile config.status: executing depfiles commands config.status: executing libtool commands gmake[3]: Entering directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr' Making all in doc gmake[4]: Entering directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr/doc' restore=: && backupdir=".am$$" && \ am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc && \ rm -rf $backupdir && mkdir $backupdir && \ if (makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --version) >/dev/null 2>&1; then \ for f in ../../../gcc-12.2.0/mpfr/doc/mpfr.info ../../../gcc-12.2.0/mpfr/doc/mpfr.info-[0-9] ../../../gcc-12.2.0/mpfr/doc/mpfr.info-[0-9][0-9] ../../../gcc-12.2.0/mpfr/doc/mpfr.i[0-9] ../../../gcc-12.2.0/mpfr/doc/mpfr.i[0-9][0-9]; do \ if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \ done; \ else :; fi && \ cd "$am__cwd"; \ if makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 --enable-encoding -I ../../../gcc-12.2.0/mpfr/doc \ -o ../../../gcc-12.2.0/mpfr/doc/mpfr.info ../../../gcc-12.2.0/mpfr/doc/mpfr.texi; \ then \ rc=0; \ CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc; \ else \ rc=$?; \ CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc && \ $restore $backupdir/* `echo "./../../../gcc-12.2.0/mpfr/doc/mpfr.info" | sed 's|[^/]*$||'`; \ fi; \ rm -rf $backupdir; exit $rc mkdir: .am388: Permission denied ../../../gcc-12.2.0/mpfr/doc/mpfr.info: Permission denied gmake[4]: *** [Makefile:380: ../../../gcc-12.2.0/mpfr/doc/mpfr.info] Error 1 gmake[4]: Leaving directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr/doc' gmake[3]: *** [Makefile:500: all-recursive] Error 1 gmake[3]: Leaving directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr' gmake[2]: *** [Makefile:7094: all-stage1-mpfr] Error 2 gmake[2]: Leaving directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001' gmake[1]: *** [Makefile:27609: stage1-bubble] Error 2 gmake[1]: Leaving directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001' gmake: *** [Makefile:28222: bootstrap4] Error 2 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. So I did a chgrp "foo" on that whole dir and also allowed common dirt humans to read and write the mpfr.info file. That seems to allow bootstrap to continue for those dirty users. Not sure if anyone else sees this as a bug or just a feature. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Please make your subject more specific next time. Anything can be an annoying little thing :). On Wed, 2022-08-24 at 00:21 -0400, Dennis Clarke via Gcc-help wrote: > > Dear ALL : > > 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. To whoever reading this: if you really want to do that, remember to use --no-same-owner when you invoke tar to extract the tarball. Or you may leave some files or directories with UID = (the UID of whoever created this tarball on his system). /* snip */ > if makeinfo --split-size=5000000 --split-size=5000000 > --split-size=5000000 --enable-encoding -I ../../../gcc- > 12.2.0/mpfr/doc \ > -o ../../../gcc-12.2.0/mpfr/doc/mpfr.info > ../../../gcc-12.2.0/mpfr/doc/mpfr.texi; \ > then \ > rc=0; \ > CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc; \ > else \ > rc=$?; \ > CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc && \ > $restore $backupdir/* `echo > "./../../../gcc-12.2.0/mpfr/doc/mpfr.info" | sed 's|[^/]*$||'`; \ > fi; \ > rm -rf $backupdir; exit $rc > 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'll not call this a bug: if you, as a distributor, want to distribute the MPFR source code to others, you should use "make dist" to generate a tarball and distribute it, instead of providing others a "dirty" tree. This is how a package using autoconf/automake is distributed. [GCC itself is an exception: we version control the generated files to be included in the release tarball, instead of using "make dist" to generate them on release. But our approach for GCC also causes a different kind of nasty issues (for example, if a generated file is merged by git during a "git cherry-pick", the content will be likely incorrect).] And no matter it's a bug or not, there is nothing we can do on GCC side because MPFR is not a part of GCC. -- Xi Ruoyao <xry111@xry111.site> School of Aerospace Science and Technology, Xidian University
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. 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 The -Z is what's critical here: it sets the timestamps of the patched files to the timestamps included in the patch itself. 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. 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 -Matthew
On Wed, 24 Aug 2022 at 05:23, Dennis Clarke via Gcc-help <gcc-help@gcc.gnu.org> wrote: > > > Dear ALL : > > 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 The GCC build will not touch the source tree unless you configure with --enable-maintainer-mode (in which case it will automatically try to re-run some autotools scripts if some of the generated files in the tree appear to be out of date). > I extract the gcc 12.2.0 tarball of joy as the root user. That's completely unnecessary. This doesn't seem like common sense, but rather creating unnecessary problems for yourself. > Then inside > that directory structure I crack out the gmp/mpfr/mpc goodness and even > apply the correct patch for mpfr[1]. Not sure what the [1] refers to, but I think I've said before that you can just use the recommended versions that are downloaded by the download_prerequisites script, and not worry about patching anything. > > So anyways, funny thing happens when I try to build out of tree : > 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? You extracted the tarballs as root. > Could be the mpfr guys but hey this seems weird. > > So I did a chgrp "foo" on that whole dir and also allowed common dirt > humans to read and write the mpfr.info file. That seems to allow > bootstrap to continue for those dirty users. Not sure if anyone else > sees this as a bug or just a feature. Either way, it's not a GCC problem.
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 > <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@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 mimas# mimas# /usr/bin/patch --version Patch version 2.0-12u8-NetBSD
On 08.24.2022 12:51, Dennis Clarke wrote: >------------------ From the GCC Help Maillist ------------------ >On 8/24/22 04:27, Matthew R. Wilson wrote: >>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: >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 > >>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. The "you can safely ignore it" applies to specifically the warning when trying to set the time on the PATCHES file, not that you can safely ignore the entire -Z option (or lack thereof). >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? If the patch utility that comes with NetBSD does not have the -Z option, then yes, that seems to be a problem for the workflow you're trying to accomplish (protected source tree but using an 'unclean' source distribution of MPFR during the build since the effects of the -Z option aren't being correctly applied). -Matthew
On 2022-08-24 11:04:23 -0700, Matthew R. Wilson wrote: > > 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. > > The "you can safely ignore it" applies to specifically the warning when > trying to set the time on the PATCHES file, not that you can safely > ignore the entire -Z option (or lack thereof). > > > 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? > > If the patch utility that comes with NetBSD does not have the -Z option, > then yes, that seems to be a problem for the workflow you're trying to > accomplish (protected source tree but using an 'unclean' source > distribution of MPFR during the build since the effects of the -Z option > aren't being correctly applied). I'll update the MPFR text later in order to clarify it and give more details. If the -Z option is not available, I suggest to use the --disable-maintainer-mode configure option in order to avoid the unnecessary rebuilds (which the -Z patch option allows to avoid). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
On 8/24/22 15:23, Vincent Lefevre wrote:
> --disable-maintainer-mode confi
Thank you for the reply and I just wanted to clarify that this problem
happened within a bootstrap of GCC 12.2.0 on NetBSD. I was surprised
to see :
.
.
.
checking if gmp_printf supports the ' group flag... yes
checking for __gmpn_sbpi1_divappr_q... yes
checking for __gmpn_invert_limb... no
checking for __gmpn_rsblsh1_n... no
checking for long to fit in mp_limb_t... yes
checking for intmax_t to fit in mp_limb_t... yes
checking for getrusage... yes
configure: updating cache ./config.cache
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating mpfr.pc
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating tests/Makefile
config.status: creating tune/Makefile
config.status: creating src/mparam.h
config.status: creating tools/bench/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
gmake[3]: Entering directory
'/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr'
Making all in doc
gmake[4]: Entering directory
'/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd
../../../gcc-12.2.0/mpfr/doc && \
rm -rf $backupdir && mkdir $backupdir && \
if (makeinfo --split-size=5000000 --split-size=5000000
--split-size=5000000 --version) >/dev/null 2>&1; then \
for f in ../../../gcc-12.2.0/mpfr/doc/mpfr.info
../../../gcc-12.2.0/mpfr/doc/mpfr.info-[0-9]
../../../gcc-12.2.0/mpfr/doc/mpfr.info-[0-9][0-9]
../../../gcc-12.2.0/mpfr/doc/mpfr.i[0-9]
../../../gcc-12.2.0/mpfr/doc/mpfr.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi && \
cd "$am__cwd"; \
if makeinfo --split-size=5000000 --split-size=5000000
--split-size=5000000 --enable-encoding -I ../../../gcc-12.2.0/mpfr/doc \
-o ../../../gcc-12.2.0/mpfr/doc/mpfr.info
../../../gcc-12.2.0/mpfr/doc/mpfr.texi; \
then \
rc=0; \
CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc; \
else \
rc=$?; \
CDPATH="${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/doc && \
$restore $backupdir/* `echo
"./../../../gcc-12.2.0/mpfr/doc/mpfr.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
mkdir: .am388: Permission denied
../../../gcc-12.2.0/mpfr/doc/mpfr.info: Permission denied
gmake[4]: *** [Makefile:380: ../../../gcc-12.2.0/mpfr/doc/mpfr.info] Error 1
gmake[4]: Leaving directory
'/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr/doc'
gmake[3]: *** [Makefile:500: all-recursive] Error 1
gmake[3]: Leaving directory
'/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001/mpfr'
gmake[2]: *** [Makefile:7094: all-stage1-mpfr] Error 2
gmake[2]: Leaving directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001'
gmake[1]: *** [Makefile:27609: stage1-bubble] Error 2
gmake[1]: Leaving directory '/opt/bw/build/gcc-12.2.0_NetBSD_9.3_AMD64.001'
gmake: *** [Makefile:28222: bootstrap4] Error 2
So that was when I simply corrected the things in ./doc directory and
continued onwards. I think I need GNU patch to avoid this problem within
a GCC bootstrap.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On 2022-08-24 21:23:13 +0200, Vincent Lefevre wrote: > I'll update the MPFR text later in order to clarify it and give more > details. The text on https://www.mpfr.org/mpfr-current/ is now: Because make's rebuild decisions are based on timestamps, the -Z option is highly recommended: it sets the modification time of the patched files from timestamps given in the patch file, thus avoiding unnecessary rebuilds that could need some development utilities (such as autoconf); for the special PATCHES file, this may generate a "Not setting time" warning, which you can safely ignore. If the -Z option is not available, you can also avoid the unnecessary rebuilds by using the --disable-maintainer-mode configure option later. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)