At Thu, 7 Oct 2021 23:17:33 +0000 (UTC), RVP <rvp%SDF.ORG@localhost> wrote: Subject: Re: very strange build failure in external/gpl3/gcc/lib/libstdc++-v3/include/bits > > On Thu, 7 Oct 2021, Greg A. Woods wrote: > > > It's almost as if the call to rename() in 'mv' succeeds, but returns an > > ENOENT error sometimes!!! > > > > Or, there's a race to completion happening. Is libstdc++-v3 being built > twice? Yes that's quite likely. I realised the same just after I wrote my message and went out to do some yard work. If two identical 'mv' commands run in the same directory (with no other commands running there in between) then the second one is going to report an ENOENT error. Given these 'mv' commands are on the tail of a command list that creates the source file, they have to run very nearly in parallel in order to trigger the observed failure. I'm not sure yet how or where these built include files get specified twice, or in whatever way that causes them to be built multiple times in parallel. Perhaps it's the trickery here (interfering with similar trickery in <bsd.inc.mk>)? /usr/src/external/gpl3/gcc/lib/libstdc++-v3/include/Makefile.includes Or given that c++config.h was also in the same boat, maybe all of external/gpl3/gcc/lib/libstdc++-v3/include/bits is being built twice for the "includes" target? > PS. I should ask: your machines are all running NTP, right? Yes indeed, though the second machine is using all local disk. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpduHDYtr3Nq.pgp
Description: OpenPGP Digital Signature