Created attachment 29983 [details] Full build log When building gcc-4.8 (patched by OpenEmbedded) with '-j 8', the build fails from time to time because bconfig.h can not be found. A subsequent make succeeds in these cases.
This was partially fixed by http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01682.html but gengtype.c, gengtype-parse.c, and gengtype-state.c also include bconfig.h if -DGENERATOR_FILE is defined.
In this matter I'm quite confused by the intentions of http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00273.html It states that host object files depend on CONFIG_H, but these seem to get in fact built with -DGENERATOR_FILE (according to build log), so through gentype.c, they include bconfig.h instead of config.h. I don't see that reflected in build dependencies, and more importantly, I'm not even sure this consequence was intended/correct.
As another data point, I have randomly encountered this issue on ia64 with gcc-4.7.3 gcc -c -DUSE_LIBUNWIND_EXCEPTIONS -O0 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -Wno-error -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I/home/buildbot/build/sage/iras-1/sage_git/build/local/include -I/home/buildbot/build/sage/iras-1/sage_git/build/local/include -I/home/buildbot/build/sage/iras-1/sage_git/build/local/include -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber ../../src/gcc/gengtype-lex.c -o gengtype-lex.o ../../src/gcc/gengtype-lex.c:1:21: fatal error: bconfig.h: No such file or directory compilation terminated. make[6]: *** [gengtype-lex.o] Error 1
For 4.7, the patch in comment #1 did the trick for us. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.7.3/gentoo/93_all_4.8.0_gengtype-lex_parallel_build.patch
Created attachment 33419 [details] Possible fix Attached is a patch which appears to fix this issue for me (on gcc 4.8.3). In gcc/Makefile.in there is a comment: # The gengtype generator program is special: Two versions are built. # One is for the build machine, and one is for the host to allow # plugins to define their types and generate the supporting GGC # datastructures and routines with GTY markers. # The host object files depend on CONFIG_H, and the build objects # on BCONFIG_H. For the build objects, add -DGENERATOR_FILE manually, # the build-%: rule doesn't apply to them. The change I chose to make swaps the make dependencies around, alternatively GENERATOR_FILE may defined in the wrong case. I'm not sure what the right behaviour is here, or which set of objects is which!
Sorry, this patch doesn't seem sufficient (perhaps I was just lucky for a while). Apologies for the noise.
I'm seeing this with gentoo's gcc-4.9.2
(In reply to Vladimír Čunát from comment #2) i think you're spot on -- the logic is inverted (In reply to Andrew Oakley from comment #5) i think this patch is incorrect. you're inverting what the Makefile explicitly is saying to do. namely, build/%.o should be depending on $(BCONFIG_H) and they should be building with -DGENERATOR_FILE. so the CFLAGS- lines need fixing. looking at trunk, this appears to be fixed here: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=218325 the compile logic was inverted so that bconfig.h is included by default, and to get config.h you have to define HOST_GENERATOR_FILE. then the CFLAGS-xxx line was updated to use that. i guess we keep this open so hopefully it'll get backported to gcc-4.9 ?
after having the backport deployed in Gentoo, we found an edge case with the fix in trunk ... we still have this rule in gcc/Makefile.in: # Generated source files for gengtype. Prepend inclusion of # bconfig.h because AIX requires _LARGE_FILES to be defined before # any system header is included. gengtype-lex.c : gengtype-lex.l -$(FLEX) $(FLEXFLAGS) -o$@ $< && { \ echo '#include "bconfig.h"' > $@.tmp; \ cat $@ >> $@.tmp; \ mv $@.tmp $@; \ } so even though gengtype-lex.l was adapted to not include bconfig.h when HOST_GENERATOR_FILE is defined, and the bconfig.h dep on that file was dropped, the source still tries to always include it for both host & build modes. i don't really understand the comment ... it seems to me that the lex file will include the right config.h header files first already, so we should drop the explicit insertion of bconfig.h here.
f142b5bc2102 (Romain Geissler 2011-08-04 11:30:45 +0000 2872) gengtype-lex.o build/gengtype-lex.o : gengtype-lex.c gengtype.h $(SYSTEM_H) d6d34aa9133a (Jakub Jelinek 2014-12-03 17:44:27 +0100 2873) CFLAGS-gengtype-lex.o += -DHOST_GENERATOR_FILE f142b5bc2102 (Romain Geissler 2011-08-04 11:30:45 +0000 2874) build/gengtype-lex.o: $(BCONFIG_H) 18406601136a (Paolo Bonzini 2010-11-13 09:42:58 +0000 3001) # Generated source files for gengtype. Prepend inclusion of 8c7dbea9f193 (Boris Kolpackov 2017-11-26 13:00:48 +0000 3002) # config.h/bconfig.h because AIX requires _LARGE_FILES to be defined before 18406601136a (Paolo Bonzini 2010-11-13 09:42:58 +0000 3003) # any system header is included. 03787dfd8153 (Kelley Cook 2004-01-15 04:02:24 +0000 3004) gengtype-lex.c : gengtype-lex.l 8fb15466274a (Paolo Bonzini 2010-11-11 23:44:44 +0000 3005) -$(FLEX) $(FLEXFLAGS) -o$@ $< && { \ 8c7dbea9f193 (Boris Kolpackov 2017-11-26 13:00:48 +0000 3006) echo '#ifdef HOST_GENERATOR_FILE' > $@.tmp; \ 8c7dbea9f193 (Boris Kolpackov 2017-11-26 13:00:48 +0000 3007) echo '#include "config.h"' >> $@.tmp; \ 8c7dbea9f193 (Boris Kolpackov 2017-11-26 13:00:48 +0000 3008) echo '#else' >> $@.tmp; \ 8c7dbea9f193 (Boris Kolpackov 2017-11-26 13:00:48 +0000 3009) echo '#include "bconfig.h"' >> $@.tmp; \ 8c7dbea9f193 (Boris Kolpackov 2017-11-26 13:00:48 +0000 3010) echo '#endif' >> $@.tmp; \ 8fb15466274a (Paolo Bonzini 2010-11-11 23:44:44 +0000 3011) cat $@ >> $@.tmp; \ 8fb15466274a (Paolo Bonzini 2010-11-11 23:44:44 +0000 3012) mv $@.tmp $@; \ 8fb15466274a (Paolo Bonzini 2010-11-11 23:44:44 +0000 3013) } So this was fixed with r8-4925-g8c7dbea9f193