public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dennis Clarke <dclarke@blastwave.org>
To: "Matthew R. Wilson" <mwilson@mattwilson.org>
Cc: gcc-help@gcc.gnu.org, mpfr@inria.fr
Subject: Re: one of those annoying little things
Date: Wed, 24 Aug 2022 12:51:59 -0400	[thread overview]
Message-ID: <da7d0f9d-0295-6939-5a02-ae5ed802ae30@blastwave.org> (raw)
In-Reply-To: <20220824082743.3jqs3owseaulpjh7@mattwilson.org>


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


  reply	other threads:[~2022-08-24 16:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-24  4:21 Dennis Clarke
2022-08-24  5:20 ` Xi Ruoyao
2022-08-24  8:27   ` Matthew R. Wilson
2022-08-24 16:51     ` Dennis Clarke [this message]
2022-08-24 18:04       ` Matthew R. Wilson
2022-08-24 19:23         ` Vincent Lefevre
2022-08-24 19:43           ` Dennis Clarke
2022-08-24 20:00           ` Vincent Lefevre
2022-08-24 11:26 ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da7d0f9d-0295-6939-5a02-ae5ed802ae30@blastwave.org \
    --to=dclarke@blastwave.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=mpfr@inria.fr \
    --cc=mwilson@mattwilson.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).