On Jun 26, 2017, Olivier Hainque <hain...@adacore.com> wrote: > On Jun 22, 2017, at 14:12 , Alexandre Oliva <aol...@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 <hain...@adacore.com> wrote: >> On Jun 26, 2017, at 09:16 , Olivier Hainque <hain...@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
