On 12/04/2015 05:39 AM, Szabolcs Nagy wrote:
As described in pr other/67627, the all-multi target can be
built in parallel with the %_.lo targets which generate make
dependencies that are parsed during the build of all-multi.
gcc -MD does not generate the makefile dependencies in an
atomic way so make can fail if it concurrently parses those
half-written files.
(not observed on x86, but happens on arm native builds.)
this workaround forces all-multi to only run after the *_.lo
targets are done, but there might be a better solution using
automake properly. (automake should know about the generated
make dependency files that are included into the makefile so
no manual tinkering is needed to get the right build order,
but i don't know how to do that.)
2015-12-04 Szabolcs Nagy <szabolcs.n...@arm.com>
PR other/67627
* Makefile.am (all-multi): Add dependency.
* Makefile.in: Regenerate.
ISTM that many of the libraries have this problem.
[law@localhost gcc]$ grep all-am: */Makefile.in | grep -v install
boehm-gc/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi
gotools/Makefile.in:all-am: Makefile $(PROGRAMS) $(MANS)
libatomic/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi
auto-config.h
libbacktrace/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi config.h
libcc1/Makefile.in:all-am: Makefile $(LTLIBRARIES) cc1plugin-config.h
libcilkrts/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi $(HEADERS)
libffi/Makefile.in:all-am: Makefile $(INFO_DEPS) $(LTLIBRARIES)
all-multi $(DATA) \
libgfortran/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi
$(DATA) $(HEADERS) config.h
libgo/Makefile.in:all-am: Makefile $(LIBRARIES) $(LTLIBRARIES) all-multi
$(DATA) \
libgomp/Makefile.in:all-am: Makefile $(INFO_DEPS) $(LTLIBRARIES)
all-multi $(HEADERS) \
libitm/Makefile.in:all-am: Makefile $(INFO_DEPS) $(LTLIBRARIES)
all-multi $(HEADERS) \
libjava/Makefile.in:all-am: Makefile $(LTLIBRARIES) $(PROGRAMS)
$(SCRIPTS) all-multi \
libmpx/Makefile.in:all-am: Makefile all-multi $(HEADERS) config.h
liboffloadmic/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi
$(HEADERS) all-local
libquadmath/Makefile.in:all-am: Makefile $(INFO_DEPS) $(LTLIBRARIES)
all-multi $(HEADERS) \
libsanitizer/Makefile.in:all-am: Makefile all-multi $(HEADERS) config.h
libssp/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi $(HEADERS)
config.h
libstdc++-v3/Makefile.in:all-am: Makefile all-multi config.h
libvtv/Makefile.in:all-am: Makefile $(LTLIBRARIES) all-multi $(HEADERS)
lto-plugin/Makefile.in:all-am: Makefile $(LTLIBRARIES) config.h all-local
zlib/Makefile.in:all-am: Makefile $(LIBRARIES) $(LTLIBRARIES) all-multi
And if you look at the all-multi targets in each of those, all-multi has
no dependencies. So any of them which use auto-dependency generation
are potentially going to bump into this problem.
We can't fix it by twiddling Makefile.in as that's a generated file. I
think it has to happen at the automake level.
jeff
