libjava broken vs make -j?

Wed Aug 26 21:41:00 GMT 2009

 I just started seeing this, with "make -j4":
> make[4]: Leaving directory `/gnu/gcc/obj-java2/i686-pc-cygwin/boehm-gc'
> make[3]: Leaving directory `/gnu/gcc/obj-java2/i686-pc-cygwin/boehm-gc'
> make[2]: Leaving directory `/gnu/gcc/obj-java2/i686-pc-cygwin/boehm-gc'
> make[2]: Entering directory `/gnu/gcc/obj-java2/i686-pc-cygwin/libjava'
> : make ; exec make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc-4" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "CPPFLAGS=" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "GCJFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/opt/gcc-tools" "datadir=/opt/gcc-tools/share" "infodir=/opt/gcc-tools/share/info" "libdir=/opt/gcc-tools/lib" "mandir=/opt/gcc-tools/share/man" "prefix=/opt/gcc-tools" "gxx_include_dir=/opt/gcc-tools/lib/gcc/i686-pc-cygwin/4.5.0/include/c++" "AR=/opt/gcc-tools/i686-pc-cygwin/bin/ar" "AS=/gnu/gcc/obj-java2/./gcc/as" "LD=/gnu/gcc/obj-java2/./gcc/collect-ld" "LIBCFLAGS=-g -O2" "NM=/gnu/gcc/obj-java2/./gcc/nm" "PICFLAG=" "RANLIB=/opt/gcc-tools/i686-pc-cyg
win/bin/ranlib" "DESTDIR=" "JAR=/gnu/gcc/obj-java2/i686-pc-cygwin/libjava/scripts/jar" DO=all multi-do
> make create-headers
> make[3]: Entering directory `/gnu/gcc/obj-java2/i686-pc-cygwin/libjava'
> make[3]: *** No rule to make target `classpath/lib/compile-classes', needed by `gcjh.stamp'. Stop.
> make[3]: Leaving directory `/gnu/gcc/obj-java2/i686-pc-cygwin/libjava'
> make[2]: *** [headers.stamp] Error 2
> make[2]: *** Waiting for unfinished jobs....
> make[3]: Entering directory `/gnu/gcc/obj-java2/i686-pc-cygwin/libjava'

 There is indeed no rule to make classpath/lib/compile-classes, as it's
generated in a recursive sub-make (which would happen earlier in a
non-parallel build, or at lower -j levels, rather than simultaneously and
racily as here). Presumably we need to add some dependency at the top level,
perhaps something like this?
classpath/lib/compile-classes: all-multi
 cheers,
 DaveK