Re: Still with the Java testsuite failures

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Zack" == Zack Weinberg <zackw@stanford.edu> writes:

Zack> I am still observing ~800 spurious failures in the Java testsuite.
Zack> This is the mainline [ ... ]

I don't know about anybody else, but I haven't been looking at the
trunk at all.  There are a few reasons: it couldn't bootstrap Java for
a while (more than a week), I have limited time right now for Java
hacking, and there are gcc 3.0 issues that are more important.

Zack> PASS: Array_1 compilation from bytecode
Zack> lt-Array_1: error while loading shared libraries: libgcc_s.so.0: 
Zack> 	cannot load shared object file: No such file or directory
Zack> FAIL: Array_1 execution from bytecode->native test

Zack> This is the same problem the objc test suite had a couple of weeks
Zack> back.  Somewhere, LD_LIBRARY_PATH needs to be augmented with the gcc
Zack> build directory.

It might be appropriate to fix this in dejagnu.  It looks like dejagnu
already handles this stuff sometimes.  However, that would be the
route of maximal pain.  So instead I've come up with this patch, which
works for me.  Could you try it?

If this works for you I will check it in.  (It will go on the branch
too, since it is needed there.)

2001-03-16  Tom Tromey  <tromey@redhat.com>

	* lib/libjava.exp (libjava_arguments): Rewrote computation of
	LD_LIBRARY_PATH.  Add gcc build directory if it contains
	libgcc_s.so.

Zack> jc1: No such file or directory: can't open ^?ELF^A^A^A

Zack> This looks like a serious driver or spec bug.

I'm guessing this is related to Per's changes to the driver.  These
changes are only on the trunk.  I'm afraid I definitely won't be
looking at this in the near future.  Per checked in some patches in
this area tonight; maybe one of them fixes the problem.

Tom

Index: lib/libjava.exp
===================================================================
RCS file: /cvs/gcc/gcc/libjava/testsuite/lib/libjava.exp,v
retrieving revision 1.22
diff -u -r1.22 libjava.exp
--- libjava.exp	2001/01/17 06:45:40	1.22
+++ libjava.exp	2001/03/16 07:03:32
@@ -1,4 +1,4 @@
-# Copyright (C) 1998, 1999, 2000 Free Software Foundation
+# Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation
 
 load_lib "libgloss.exp"
 
@@ -192,6 +192,7 @@
     global tmpdir
     global runtests
     global env
+    global tool_root_dir
 
     if [info exists LIBJAVA] {
 	set libjava $LIBJAVA;
@@ -229,18 +230,26 @@
 
     # Basically we want to build up a colon separated path list from
     # the value of $libjava.
-
-    # First strip away any -L arguments.
-    regsub -all -- "-L" $libjava "" ld_library_path
 
-    # Then remove any -lgcj argument.
-    regsub -all -- " -lgcj.*" $ld_library_path "" ld_library_path
+    set lpath {}
+    foreach dir [list $libjava $libgc $libz] {
+	foreach item [split $dir " "] {
+	    switch -glob -- $item {
+		"-L*" {
+		    lappend lpath [string range $item 2 end]
+		}
+	    }
+	}
+    }
 
-    # First strip away any -L arguments.
-    regsub -all -- "-L" $libgc $ld_library_path ld_library_path
+    # Finally, add the gcc build directory so that we can find the
+    # shared libgcc.  This, like much of dejagnu, is hideous.
+    set gccdir [lookfor_file $tool_root_dir gcc/libgcc_s.so]
+    if {$gccdir != ""} {
+	lappend lpath [file dirname $gccdir]
+    }
 
-    # Then remove any -lgcjgc argument.
-    regsub -all -- " -lgcjgc.*" $ld_library_path "" ld_library_path
+    set ld_library_path [join $lpath :]
 
     # That's enough to make things work for the normal case.
     # If we wanted to handle an arbitrary value of libjava,
@@ -250,6 +259,8 @@
     global original_ld_library_path
     setenv LD_LIBRARY_PATH "$ld_library_path:$original_ld_library_path"
     setenv SHLIB_PATH "$ld_library_path:$original_ld_library_path"
+
+    verbose "LD_LIBRARY_PATH = $env(LD_LIBRARY_PATH)"
 
     # Set the CLASSPATH environment variable
     verbose "CLASSPATH is .:$srcdir/$subdir:$objdir:$objdir/../libgcj.jar"