At Thu, 7 Oct 2021 23:17:33 +0000 (UTC), RVP <[email protected]> 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 <[email protected]>
Kelowna, BC +1 250 762-7675 RoboHack <[email protected]>
Planix, Inc. <[email protected]> Avoncote Farms <[email protected]>
pgpfO3tndRvb0.pgp
Description: OpenPGP Digital Signature
