Hi Alex, > On Jun 26, 2017, at 09:16 , Olivier Hainque <hain...@adacore.com> wrote: > >> I'd like to understand better what the concurrency problem is with the >> current build machinery, before we proceed with this change. If you >> manage to trigger the problem again, could you try to further analyze >> build logs to check for e.g. concurrent activation of all-gcc in both >> the top-level Makefile and the recursed-into-for-stage1 Makefile, or >> somesuch? Something else worth considering is what the make targets >> specified in the command line were. > > The problems were showing pretty rarely, only on certain hosts, in > certain load conditions. We should still have the logs around and I'll > look into this. They are regular logs, without -d. I can almost for sure > fetch the exact "make" command line involved.
This was: 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 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 ? Thanks for your feedback! (Note that I'll be away from tomorrow to Monday) Olivier
