From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id 037593857034 for ; Wed, 24 Aug 2022 05:20:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 037593857034 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1661318447; bh=L5CInb4k4GENS02FnUxgaJuM16KOIMwEiNdFcXMoSCk=; h=Subject:From:To:Date:In-Reply-To:References:From; b=BxOj8tc1p76cMBEWkjepSJCMfRtFpXt32SE5O/nWpE33xhRrRmRfZiwPvbCIT/wB/ 208D1bfY8UwGjUsiwlqwYs5o2QRciUb8PsyH/sFpnxnSw/BJ1HnHgfqX+kUKsFdo/C 1qhjahJgRJoO2Fn+fZq5kDB4NLLqlXEXSczBDq4o= Received: from [IPv6:240e:358:113a:9c00:dc73:854d:832e:3] (unknown [IPv6:240e:358:113a:9c00:dc73:854d:832e:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id E0285667C2; Wed, 24 Aug 2022 01:20:45 -0400 (EDT) Message-ID: Subject: Re: one of those annoying little things From: Xi Ruoyao To: Dennis Clarke , gcc-help@gcc.gnu.org Date: Wed, 24 Aug 2022 13:20:38 +0800 In-Reply-To: <49c6528e-13d9-fcff-2046-6a0a167c3fea@blastwave.org> References: <49c6528e-13d9-fcff-2046-6a0a167c3fea@blastwave.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.45.2 MIME-Version: 1.0 X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD,LIKELY_SPAM_FROM,PDS_OTHER_BAD_TLD,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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: >=20 > Dear ALL : >=20 > =C2=A0=C2=A0=C2=A0=C2=A0 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 =3D (the UID of whoever created this tarball on his system). /* snip */ > if makeinfo --split-size=3D5000000 --split-size=3D5000000=20 > --split-size=3D5000000=C2=A0 --enable-encoding -I ../../../gcc- > 12.2.0/mpfr/doc \ > =C2=A0 -o ../../../gcc-12.2.0/mpfr/doc/mpfr.info=20 > ../../../gcc-12.2.0/mpfr/doc/mpfr.texi; \ > then \ > =C2=A0=C2=A0 rc=3D0; \ > =C2=A0=C2=A0 CDPATH=3D"${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/= doc; \ > else \ > =C2=A0=C2=A0 rc=3D$?; \ > =C2=A0=C2=A0 CDPATH=3D"${ZSH_VERSION+.}:" && cd ../../../gcc-12.2.0/mpfr/= doc && \ > =C2=A0=C2=A0 $restore $backupdir/* `echo=20 > "./../../../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 =3D 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.=20 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. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University