public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* one of those annoying little things
@ 2022-08-24  4:21 Dennis Clarke
  2022-08-24  5:20 ` Xi Ruoyao
  2022-08-24 11:26 ` Jonathan Wakely
  0 siblings, 2 replies; 9+ messages in thread
From: Dennis Clarke @ 2022-08-24  4:21 UTC (permalink / raw)
  To: gcc-help


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24  4:21 one of those annoying little things Dennis Clarke
@ 2022-08-24  5:20 ` Xi Ruoyao
  2022-08-24  8:27   ` Matthew R. Wilson
  2022-08-24 11:26 ` Jonathan Wakely
  1 sibling, 1 reply; 9+ messages in thread
From: Xi Ruoyao @ 2022-08-24  5:20 UTC (permalink / raw)
  To: Dennis Clarke, gcc-help

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24  5:20 ` Xi Ruoyao
@ 2022-08-24  8:27   ` Matthew R. Wilson
  2022-08-24 16:51     ` Dennis Clarke
  0 siblings, 1 reply; 9+ messages in thread
From: Matthew R. Wilson @ 2022-08-24  8:27 UTC (permalink / raw)
  To: Xi Ruoyao; +Cc: Dennis Clarke, gcc-help

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24  4:21 one of those annoying little things Dennis Clarke
  2022-08-24  5:20 ` Xi Ruoyao
@ 2022-08-24 11:26 ` Jonathan Wakely
  1 sibling, 0 replies; 9+ messages in thread
From: Jonathan Wakely @ 2022-08-24 11:26 UTC (permalink / raw)
  To: Dennis Clarke; +Cc: gcc-help

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24  8:27   ` Matthew R. Wilson
@ 2022-08-24 16:51     ` Dennis Clarke
  2022-08-24 18:04       ` Matthew R. Wilson
  0 siblings, 1 reply; 9+ messages in thread
From: Dennis Clarke @ 2022-08-24 16:51 UTC (permalink / raw)
  To: Matthew R. Wilson; +Cc: gcc-help, mpfr


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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24 16:51     ` Dennis Clarke
@ 2022-08-24 18:04       ` Matthew R. Wilson
  2022-08-24 19:23         ` Vincent Lefevre
  0 siblings, 1 reply; 9+ messages in thread
From: Matthew R. Wilson @ 2022-08-24 18:04 UTC (permalink / raw)
  To: Dennis Clarke; +Cc: gcc-help, mpfr

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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  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
  0 siblings, 2 replies; 9+ messages in thread
From: Vincent Lefevre @ 2022-08-24 19:23 UTC (permalink / raw)
  To: Matthew R. Wilson; +Cc: Dennis Clarke, gcc-help, mpfr

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)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24 19:23         ` Vincent Lefevre
@ 2022-08-24 19:43           ` Dennis Clarke
  2022-08-24 20:00           ` Vincent Lefevre
  1 sibling, 0 replies; 9+ messages in thread
From: Dennis Clarke @ 2022-08-24 19:43 UTC (permalink / raw)
  To: Matthew R. Wilson, gcc-help, mpfr

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: one of those annoying little things
  2022-08-24 19:23         ` Vincent Lefevre
  2022-08-24 19:43           ` Dennis Clarke
@ 2022-08-24 20:00           ` Vincent Lefevre
  1 sibling, 0 replies; 9+ messages in thread
From: Vincent Lefevre @ 2022-08-24 20:00 UTC (permalink / raw)
  To: Matthew R. Wilson, Dennis Clarke, gcc-help, mpfr

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)

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-08-24 20:00 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-24  4:21 one of those annoying little things Dennis Clarke
2022-08-24  5:20 ` Xi Ruoyao
2022-08-24  8:27   ` Matthew R. Wilson
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

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).