resurrecting automatic dependencies
Tom Tromey
tromey@redhat.com
Tue Jul 23 07:06:00 GMT 2013
Tom> There may be more missing dependencies. Please try out this branch if
Tom> you would. You can report bugs to me, just send the build log.
I tried -j33 on a bigger machine and found a problem with Go.
The dependency patch uses the language Makefile conventions to add some
order-only dependencies to ensure that generated files are made early
enough (this code is actually already in gcc, but it has some latent
bugs). In particular it uses the $(lang)_OBJS variable (via
ALL_HOST_OBJS).
However, Go does not set go_OBJS, so a sufficiently large -j setting
will cause a build failure, as a Go file is compiled before a generated
header.
Fixing this is simple enough in go/Make-lang.in; but this also has the
side effect of defining IN_GCC_FRONT_END for the various Go
compilations:
$(foreach file,$(ALL_HOST_FRONTEND_OBJS),$(eval CFLAGS-$(file) += -DIN_GCC_FRONTEND))
... which causes build failures for go-backend.c (uses rtl.h) and
go-lang.c (uses except.h), since with this defined, certain headers are
prohibited.
A short term solution is to keep Go using explicit dependencies.
For a long term solution ... well, I'm CCing Ian.
The except.h doesn't seem to be needed. At least, I removed the include
and go-lang.c still compiled. The go-backend.c problem looks harder,
though. Thoughts?
Tom
More information about the Gcc
mailing list