Re: fix libcc1 dependencies in toplevel Makefile

[Olivier Hainque <hainque@adacore.com>]

Hi Alex,

Thanks for your feedback and help looking into this.

> On 12 Jun 2018, at 04:50, Alexandre Oliva <oliva@gnu.org> wrote:
> 
> 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.

Yes, indeed. I intended to convey this in the
opening message of this thread by referring to concurrency
between libcc1 and libquadmath. That was admittedly
too implicit :)


> 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.

Right.

> Now, I do vaguely recall build output within the gcc subdir that
> possibly recreated the gcc/include subtree, which might explain the
> observed errors.

That's consistent at least, as the problem we had was the compilation
of a libquadmath source not finding limits.h.
 
> 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,

Nice :-)

> 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.

I'm really not familiar enough with the dependencies organization
to provide informed input here.

Maybe a reasonable effort on 1 would be good enough in practice and
we can get to 2 only as a second step if we still observe failures.

Or start with a reasonable effort on 2 to evaluate feasibility and 
get a rough guesstimate of the effort it would take to get there, then
reassess.

For sure, I'm happy to try any patch in our development (!production)
builds and see where this leads.

Thanks again for your help on this!

With Kind Regards,

Olivier