public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Matthew R. Wilson" <mwilson@mattwilson.org>
To: Xi Ruoyao <xry111@xry111.site>
Cc: Dennis Clarke <dclarke@blastwave.org>, gcc-help@gcc.gnu.org
Subject: Re: one of those annoying little things
Date: Wed, 24 Aug 2022 01:27:43 -0700	[thread overview]
Message-ID: <20220824082743.3jqs3owseaulpjh7@mattwilson.org> (raw)
In-Reply-To: <d34f2afd191c1977f2febfc5e75109d24e58fbfd.camel@xry111.site>

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


  reply	other threads:[~2022-08-24  8:27 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 [this message]
2022-08-24 16:51     ` Dennis Clarke
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=20220824082743.3jqs3owseaulpjh7@mattwilson.org \
    --to=mwilson@mattwilson.org \
    --cc=dclarke@blastwave.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=xry111@xry111.site \
    /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).