[Bug bootstrap/11933] [3.4 regression] Parallel bootstrap failure linking gij

["ro at techfak dot uni-bielefeld dot de" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11933



------- Additional Comments From ro at techfak dot uni-bielefeld dot de  2003-09-18 15:58 -------
Subject: Re:  [3.4 regression] Parallel bootstrap failure linking gij

Just for the record, here's what I've found: the problem happens on and off
during a make -j8 bootstrap on an 8-CPU Sun Fire V880 (64 GB RAM) running
Solaris 8.  Removing the failed sparc-sun-solaris2.8/libjava directory and
continuing the bootstrap often fixes the problem.

The symptom of the failure is that libjava/rmic fails to link to to many
missing symbols.  And indeed,
sparc-sun-solaris2.8/libjava/.libs/libgcj.so.4.0.0 is much smaller than
expected, many objects are missing from the libgcj link line:

java/lang/.libs/Class.o
java/lang/.libs/Object.o
[...]
java/lang/.libs/ConcreteProcess.o
gnu/classpath/.libs/Configuration.o

In the -m64 (sparcv9) case, libtool creates both objects (with and without
-fPIC), while for -m32, only the non-PIC object is generated.

Between a successful and failed build, sparc-sun-solaris2.8/libjava/libtool
differs in an important way:

-build_libtool_libs=yes
+build_libtool_libs=no

-pic_flag="-fPIC"
+pic_flag=""
@@ -6213 +6213 @@
-dlopen_support=yes
+dlopen_support=no
@@ -6216 +6216 @@
-dlopen_self=yes
+dlopen_self=unknown
@@ -6219 +6219 @@
-dlopen_self_static=no
+dlopen_self_static=unknown
@@ -6222 +6222 @@
-link_static_flag="-static"
+link_static_flag=""

Looking for build_libtool_libs in the correct one, I find

build_libtool_libs=yes
build_libtool_libs=no
build_libtool_libs=yes
build_libtool_libs=yes

whereas the broken one has

build_libtool_libs=yes
build_libtool_libs=no
build_libtool_libs=yes
build_libtool_libs=no

I haven't really found out what causes this difference, and it's difficult
to look into the configure output because with a parallel bootstrap, output
from several directories/configure runs is intermixed.  config.log isn't
helpful either: with libtool 2.13, it lacks lots of information
necessary/useful to diagnose problems.

	Rainer