fix libcc1 dependencies in toplevel Makefile

[Alexandre Oliva]

On Jun 26, 2017, Olivier Hainque <hainque@adacore.com> wrote:

> On Jun 22, 2017, at 14:12 , Alexandre Oliva <aoliva@redhat.com> wrote:
>> Your patch takes care of the build dependencies of libcc1, which should
>> avoid some scenarios that might lead to concurrency between staged and
>> non-staged builds.  However, I don't see that it ensures libcc1 will be
>> built after GCC in bootstrap scenarios; it might do so under 'make
>> bootstrap', but probably not under 'make all-libcc1'.  I think we may
>> need some additional bootstrap-only explicit dependency for that to work
>> properly.

> I don't quite understand this: we're using the same prerequisite as target
> libraries, e.g. all-target-libstdc++-v3 or all-target-libbacktrace

Not quite.  Target libraries have deps on e.g. target-libgcc, look below
the following comments in Makefile.in:

# Dependencies for target modules on other target modules are
# described by lang_env_dependencies; the defaults apply to anything
# not mentioned there.

plus, maybe-configure*-target-libgcc depend on maybe-all*-gcc (see above
those comments).  The precise deps vary per bootstrap level, or
non-bootstrap.

But after the proposed patch there are no such deps for libcc1 in the
bootstrap case, so we might very well attempt to build libcc1 in
parallel with gcc.  We shouldn't do that.

But then, it all works out because we only build all-host after
bootstrap is complete; all-stage* doesn't depend on libcc1 at all.


> and I don't see other deps for these either.

> I don't see why the sequencing constraints for libcc1 should be tighter
> than those for the target libraries.

It was not about making them tighter, just about making them present.
Right now, in the bootstrap case, they're entirely implicit, by the fact
that we complete bootstrap first, then proceed to build all-host
all-target.  This deserves at least a comment somewhere, perhaps next to
libcc1 in Makefile.def, or next to depgcc.

Something to the effect that depgcc brings in a necessary dependency
that is implicit in the bootstrap case by the fact that we firt
bootstrap, then proceed to build all-host all-target.

Perhaps instead of depgcc=true, we should have a new flag in
dependencies that indicates the dep should be non-bootstrap only.  Or
maybe the code that implements dependencies could figure it out on its
own, when it sees a dep between a non-bootstrap module and a bootstrap
one, and generate the deps within @if gcc-no-bootstrap/@endif.

I think this would get us the behavior we want in both bootstrap and
non-bootstrap cases, including the libcc1 configure dep that, as it is,
might cause GCC to be configured in parallel given the right (or rather
wrong) conditions.


On Jun 27, 2017, Olivier Hainque <hainque@adacore.com> wrote:

>> On Jun 26, 2017, at 09:16 , Olivier Hainque <hainque@adacore.com> wrote:

> make -j 32 BOOT_LDFLAGS=-Wl,--stack=0x2000000 CC=gcc 'ADAFLAGS=-W
> -Wall -gnatpg -gnata -gnatws -gnatU -gnatyN' CXXFLAGS=-O2
> BOOT_CFLAGS=-O2 CFLAGS=-O2 'LN_S=cp -p' 'BOOT_ADAFLAGS=-gnatpgn
> -gnatU' 'STAGE1_CFLAGS=-O2 -O0 -g' bootstrap

Thanks.  Given that 'bootstrap' is the only requested make target, we
can be assured that something iffy took place.  What I can't figure out
is how we even tried to build libcc1 during bootstrap, under that
configuration, because the current Makefile would only do that with
all-host, after bootstrap is complete.

> From the logs of discussions we tracked, the understanding
> of the dependency issue was that we *had* (before the patch),
> possibilities to have stage_current and maybe-all-gcc targets
> built concurrently, via

>> configure-target-libquadmath: stage_current
>> all-target-libquadmath: configure-target-libquadmath
>> maybe-all-target-libquadmath: all-target-libquadmath

>> all-target: maybe-all-target-libquadmath

> on the one hand,

>> all-libcc1: maybe-all-gcc

>> maybe-all-libcc1: all-libcc1

>> all-host: maybe-all-libcc1

> on the other hand.

> Does that make sense ?

Yeah.  Running all-gcc While unstage does its directory-moving dance
can't be good.  We can't have them both.


So, would you like to give the automatic figuring out of
non-bootstrap-on-bootstrap deps in dependencies, and guard them between
@if gcc-no-bootstrap and @endif (then both configure- and all- libcc1
deps would be adjusted this way)?  (I'm not saying it should be trivial
to do or anything like that; I'm not all that familiar with it and I'd
have to figure it out myself if I were to do it, but I think that would
be better than adding yet another means of introducing dependencies,
while leaving another risky dep in place)

Thanks,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer