On Jun 3, 2018, Alexandre Oliva <ol...@gnu.org> wrote: > On Jun 27, 2017, Alexandre Oliva <aol...@redhat.com> wrote:
>> configuration, because the current Makefile would only do that with >> all-host, after bootstrap is complete. > I have extensively studied the dependencies, and I still don't see how > all-libcc1, that is only activated as a target during the post-bootstrap > all-host build, might have been activated concurrently with > staging/unstaging. By the time we get to all-host, we've sequentially > completed bootstrap, compare, and unstage. > The only possibilities I see of something going wrong as described is a > parallel build that has bootstrap and postbootstrap targets in the > command line, or some patch that changes the dependencies so that such > targets are considered in parallel. > I could definitely use the build logs from back then, if still > available, to try to make sense of the problem. I was missing one possibility: that the problem occurred during the post-bootstrap all-host all-target build. As far as I can tell from Nicolas' analysis, this was indeed the case. I still don't see how any staging or unstaging might have taken place, but I can now see that we do reenter the gcc dir before building all-libcc1. If that reentering rebuilds anything, particularly headers, that may be enough to explain the reported symptoms. Now, I do vaguely recall build output within the gcc subdir that possibly recreated the gcc/include subtree, which might explain the observed errors. The good news is that the patch I posted the other day actually addresses this problem: the dep on stage_last is not enough to trigger a rebuild of gcc, so a post-bootstrap all-host all-target build will not reenter the bootstrapped dirs, but that dep does trigger an initial build of gcc if one has not gone through bootstrapping yet. So I see two possible ways to go from now: 1. address the previously-mentioned fragility in the patch I posted, to catch all cases of postbootstrap targets and their deps on non-postbootstrap targets. 2. revamp the bootstrap/non-bootstrap dependencies, using GNU make conditionals rather than configure-time enable/disable-bootstrap, so that we can have a different set of dependencies while running the bootstrap proper, having non-stage dependencies activated by default when any of the all-* targets are named in the command line, and also when building post-bootstrap all-host all-target. This might seem to bring the problem back, but rather by having the full dependency set, we'd avoid the race not by refraining from reentering dirs, but rather by having them entered or reentered according to the full dependencies, without mixing stage and non-stage dependencies. I'm not yet sure this is actually doable, but it seems to me that if it is, it would be more robust than what we have now. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist
