Created attachment 2420 [details]
normal (not parallel) build

Created attachment 2421 [details]
Parallel (MAXPROCESS=2) build

I can confirm that error - or at least a similar one on the OO643C 
build. It may be just a dependency problem, but cannot figure 
it out at the moment.  


Making ../../unxlngi4.pro/misc/oo-common.ldif
mkdir -p ../../unxlngi4.pro/misc/registry/schema/org/openoffice/
-------------
java -classpath
/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/xt.jar:/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/parser.jar
-Dcom.jclark.xsl.sax.parser=com.sun.xml.parser.Parser
com.jclark.xsl.sax.Driver org/openoffice/Inet.xcs
../../util/schema_val.xsl
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.val
file=org/openoffice/Inet pathSeparator=/	
java -classpath
/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/xt.jar:/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/parser.jar
-Dcom.jclark.xsl.sax.parser=com.sun.xml.parser.Parser
com.jclark.xsl.sax.Driver org/openoffice/Inet.xcs
../../util/schema_trim.xsl
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.tmp
java -classpath
/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/jaxp.jar:/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/parser.jar:../../unxlngi4.pro/class/schema.jar
-Djavax.xml.parsers.SAXParserFactory=com.sun.xml.parser.SAXParserFactoryImpl
org.openoffice.helper.PrettyPrinter
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.tmp
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.xcs
rm -f ../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.tmp
rm -f ../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.val
mkdir -p ../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/
java -classpath
/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/xt.jar:/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/parser.jar
-Dcom.jclark.xsl.sax.parser=com.sun.xml.parser.Parser
com.jclark.xsl.sax.Driver org/openoffice/Office/Calc.xcs
../../util/schema_val.xsl
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/Calc.val
file=org/openoffice/Office/Calc pathSeparator=/	
java -classpath
/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/xt.jar:/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/parser.jar
-Dcom.jclark.xsl.sax.parser=com.sun.xml.parser.Parser
com.jclark.xsl.sax.Driver org/openoffice/Office/Calc.xcs
../../util/schema_trim.xsl
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/Calc.tmp
java -classpath
/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/jaxp.jar:/usr/local/home/buildso/OO643C/solver/643/unxlngi4.pro/bin/parser.jar:../../unxlngi4.pro/class/schema.jar
-Djavax.xml.parsers.SAXParserFactory=com.sun.xml.parser.SAXParserFactoryImpl
org.openoffice.helper.PrettyPrinter
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/Calc.tmp
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/Calc.xcs
rm -f
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/Calc.tmp
rm -f
../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/Calc.val
mkdir -p ../../unxlngi4.pro/misc/registry/schema/org/openoffice/Office/
Exception in thread "main" java.lang.NoClassDefFoundError:
org/openoffice/helper/PrettyPrinter
dmake:  Error code 1, while making
'../../unxlngi4.pro/misc/registry/schema/org/openoffice/Inet.xcs'
Exception in thread "main" java.lang.NoClassDefFoundError:
org/openoffice/helper/PrettyPrinter

ERROR: Error 65280 occurred while making
/usr/local/home/buildso/OO643C/officecfg/registry/schema

The problem is, that the Jar file is created from the compiled Java
files, but there is nothing to tell dmake that the jarfile depends on
the Java classes.

It seems that there was some work done on dependencies but it is not
enabled.  Lines from tg_jar.mk:

$(JARTARGETN) .SETDIR=$(CLASSDIR) :
#$(JARTARGETN) .SETDIR=$(CLASSDIR) .SEQUENTIAL : $(JARTARGETDEP)
$(shell -cat -s $(MISC)$/$(JARTARGETN).dep )

I guess that .dep file was used to create dependencies somehow?

The use of .SETDIR is known to have problems.  The ones I am aware of
are inconsistent bahviour when calling sub makes with MAXPROCESS >1,
and it is very confusing when trying to make dependency rules:

foo : bar
baz .SETDIR xxx : foo

When trying to make foo, dmake will look for ./bar.  When trying to
make baz, it will look for xxx/bar, because of the .SETDIR in baz.

This problem happens in tg_jar.mk.  $(JARTARGETN) should declare a
dependency on the Java classes that it contains, or at least the
targets that are needed to build the Java files, such as
ALL_JAVA_TARGETS.  But because of the .SETDIR, I can't just declare:

$(JARTARGETN) : $(ALL_JAVA_TARGETS)

so, the JARTARGETN target needs to be rewritten without .SETDIR.  This
also involves work on the dependent $(JARMANIFEST), I would guess.

Reassigning to our solenv/inc/*.mk expert - ause.

Well, I've come up with another way of doing this without having to
change the existing targets:  Make a new dummy target which depends
sequentially on ALL_JAVA_TARGETS and JARTARGETN, and let ALLTAR depend
on that instead of JARTARGETN.

Two items which you might want to check:  You may like to choose
different names for the targets, and I also added a line to output the
cppumaker commandline used.

Tested with a complete OO643C build with -P5 and -P2.

Created attachment 3898 [details]
Patch against target.mk to ensure java files are compiled before jar is built

Any progress with this bug? It is still in 1.0.2...

i'm currently working on the issue but i'm afraid it won't get fixed
on a OOo 1.0.* version as it requires changes in the jar packing i do
not regard as "stable" yet.

What about applying my version of the patch (id 3898) to STABLE_1? 
I've been using this for weeks without any problems.

could someone please confirm that this issue is fixed in ooo11beta
even with MAXPROCESS > 5 or more?
if it is, i'll retarget this issue to OOo 1.0.3 and apply the patch
(if OOO_STABLE_1 is open again).

I can confirm it - I've just finished the build of 1.1Beta with
MAXPROCESS=8.

retargeted - now waiting for OOO_STABLE_1 to reopen.

commited changes from patch to OOO_STABLE_1

-