tests: gcj cannot reliably compile directly to .o from .java

Some 4.3.x and 4.4.x releases of gcj insert a spurious 'dummy'
symbol into every object file when compiling directly from .java
to .o:
* tests/convenience.at (GCJ): make .class files from .java
sources first, and then compile those to native objects. This
works around http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143

Signed-off-by: Gary V. Vaughan <gary@gnu.org>

diff --git a/tests/convenience.at b/tests/convenience.at
index b0d4b59f448a9d29ecc588bfa46af99d5771ce4f..94ba11962f8ff7d1e8b62b189a8043d30be95a62 100644 (file)
--- a/tests/convenience.at
+++ b/tests/convenience.at
@@ -259,8 +259,16 @@ public class A$i {
 };
 EOF
 
-  $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.java
-  $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c A$i.java
+  # Workaround http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143
+  # Some 4.3.x and 4.4.x releases of gcj insert a spurious dummy symbol
+  # into every object file when compiling directly from .java to .o, so
+  # we have to make .class files first, and then compile those to native
+  # objects:
+  $GCJ $GCJFLAGS -C foo$i.java
+  $GCJ $GCJFLAGS -C A$i.java
+
+  $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c foo$i.class
+  $LIBTOOL --tag=GCJ --mode=compile $GCJ $GCJFLAGS -c A$i.class
   $LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba$i.la A$i.lo
 done
 AT_CHECK([$LIBTOOL --tag=GCJ --mode=link $GCJ $GCJFLAGS $LDFLAGS -o liba12.la liba1.la liba2.la -rpath /notexist],