Re: fix libcc1 dependencies in toplevel Makefile

[Alexandre Oliva <oliva@gnu.org>]

On Jun  3, 2018, Alexandre Oliva <oliva@gnu.org> wrote:

> On Jun 27, 2017, Alexandre Oliva <aoliva@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