Re: how to track down parallel build issues?

On Sat, May 22, 2010 at 06:32:14PM +0200, Andreas Radke <[email protected]> wrote:
> Am Mon, 12 Apr 2010 14:33:17 +0200
> schrieb Petr Mladek <[email protected]>:
>  
> > What do you mean with "I can build the package with -j1"? Do you mean
> > that the error does not happen when you build with -j1?
> 
> Yes. Build finished when built non-smp.

Strange, I get a similar error while packaging m19 with -j1 as well.

We're using gcj for the java part. m17 built fine, but with m19 I get:

    WARNING: Using swriter_en-US.zip instead of swriter_ur-IN.zip
... analyzing files with flag ARCHIVE ...
... analyzing files with flag SUBST_FILENAME ...
... analyzing files with flag SCPZIP_REPLACE ...
... analyzing files with flag PATCH_SO_NAME ...
... analyzing files with flag HIDDEN ...
... creating preregistered services.rdb ...
javavm.uno.so
javaloader.uno.so
stocservices.uno.so

**************************************************
ERROR: ERROR: Could not register all components for file services.rdb (gid_Starregistry_Services_Rdb)!
in function: create_services_rdb
**************************************************

**************************************************
ERROR: Saved logfile: /var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/instsetoo_native/util/OpenOffice//logging/6de2d257062a6c8705cbb59c75903c32/log_OOO320.log
**************************************************
... cleaning the output tree ...
... removing directory /tmp/ooopackaging/i_295961275993997 ...
Tue Jun  8 12:56:31 2010 (09:54 min.)
Failed to install:  at ./ooinstall line 154.
make: *** [install] Error 1

Greping for failed/SUCCESS in the log gives:

$ grep -c failed /var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/instsetoo_native/util/OpenOffice//logging/6de2d257062a6c8705cbb59c75903c32/log_OOO320.log
16
$ grep -c SUCCESS /var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/instsetoo_native/util/OpenOffice//logging/6de2d257062a6c8705cbb59c75903c32/log_OOO320.log
12852

So it's not just LuceneHelpWrapper.jar. The log for a given jar is like
this:

Systemcall:  /var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin/regcomp -register -br /tmp/ooopackaging/i_295961275993997/unxlngi6.pro/OpenOffice//gid_Starregistry_Services_Rdb_servicesrdb/lang_114_id_6de2d257_inprogress_1/regcomp.rdb -r /tmp/ooopackaging/i_295961275993997/unxlngi6.pro/OpenOffice//gid_Starregistry_Services_Rdb_servicesrdb/lang_114_id_6de2d257_inprogress_1/services.rdb -c 'file:///var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin/LuceneHelpWrapper.jar' -l com.sun.star.loader.Java2 -wop='vnd.sun.star.expand:$OOO_BASE_DIR/program/classes/' -env:URE_INTERNAL_JAVA_DIR='file:///var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin' 2>&1 |
file:///var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin/LuceneHelpWrapper.jar
[Java framework] The JRE specified by the bootstrap variable UNO_JAVA_JFW_JREHOME  or  UNO_JAVA_JFW_ENV_JREHOME  could not be recognized. Check the values and make sure that you use a plug-in library that can recognize that JRE.
register component 'file:///var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin/LuceneHelpWrapper.jar' in registry '/tmp/ooopackaging/i_295961275993997/unxlngi6.pro/OpenOffice//gid_Starregistry_Services_Rdb_servicesrdb/lang_114_id_6de2d257_inprogress_1/services.rdb' failed!
error (RuntimeException): [JavaVirtualMachine]:An unexpected error occurred while starting Java!
ERROR:  /var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin/regcomp -register -br /tmp/ooopackaging/i_295961275993997/unxlngi6.pro/OpenOffice//gid_Starregistry_Services_Rdb_servicesrdb/lang_114_id_6de2d257_inprogress_1/regcomp.rdb -r /tmp/ooopackaging/i_295961275993997/unxlngi6.pro/OpenOffice//gid_Starregistry_Services_Rdb_servicesrdb/lang_114_id_6de2d257_inprogress_1/services.rdb -c 'file:///var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin/LuceneHelpWrapper.jar' -l com.sun.star.loader.Java2 -wop='vnd.sun.star.expand:$OOO_BASE_DIR/program/classes/' -env:URE_INTERNAL_JAVA_DIR='file:///var/tmp/fst/src/ooo-build-3-2-1-3-16-gc38220b/build/ooo320-m19/solver/320/unxlngi6.pro/bin' 2>&1 |

I would think that it may be a gcj bug, but this is gcj-4.5 and m17
already built fine with this gcj version.

( I checked that Caolan said as well, but the Class-Path entry is not
missing.

Full log is here:

http://frugalware.org/~vmiklos/logs/log_OOO320.log )

Can't be this related to too long filenames? Given that I build with
--with-lang=ALL, it may cause the problem.

Any ideas? :)

Thanks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwOaFkACgkQe81tAgORUJa+9QCghjG5F9qtt4Whe5/6NLzDi+GU
+d4Ani0xC5dMaQBALfkRHLWp+JRWYSM+
=jZRS
-----END PGP SIGNATURE-----