Between 20090522 and 20090702, all sparcv9 libjava execution tests started to fail. libjava.log reveals: set_ld_library_path_env_vars: ld_library_path=.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc Setting LD_LIBRARY_PATH to .:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc:.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libstdc++-v3/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libssp/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libgomp/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./prev-gcc ld.so.1: PR9577: fatal: /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: PR9577 run Compared to the 20090522 log entry set_ld_library_path_env_vars: ld_library_path=.:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs:/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc Executing on host: /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc/gcj -B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/ -B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include --encoding=UTF-8 -B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../ /vol/gcc/src/gcc-dist/libjava/testsuite/libjava.cni/PR9577.jar natPR9577.o -w -no-install --main=PR9577 -g -L/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/sparcv9/libjava/.libs -lm -m64 -o PR9577 (timeout = 300) PASS: linking PR9577 the sparcv9 subdirectory is missing from gcc in the LD_LIBRARY_PATH, so the wrong libgcc_s.so.1 is found. This is most likely due to this change: 2009-06-30 Richard Sandiford <r.sandiford@uk.ibm.com> * testsuite/lib/libjava.exp (libjava_init): Just add find_libgcc_s to libjava_libgcc_s_path, rather than every libgcc multilib directory. (libjava_arguments): Explain why we add "." to ld_library_path. (gcj_invoke, exec_gij, libjava_invoke): Use add_path.
Same problem on i386-pc-solaris2.10 as of 20090702 (new since 20090622).
Do you only see this for libjava?
Subject: Re: [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC rsandifo at gcc dot gnu dot org writes: > Do you only see this for libjava? Yes, all other library tests are normal (no massive differences between 32 and 64 bit). Rainer
OK, I'm going to need some help debugging this one. First of all, how are you running your tests? E.g. (a) are you using --target_board unix/-m64, (b) is -m64 the default, or (c) something else? Second, this: [find_libgcc_s $GCJ_UNDER_TEST] is supposed to return the directory of the 64-bit libgcc, but presumably it isn't doing. Could you compare the result of that command with something like: [find_libgcc_s $GFORTRAN_UNDER_TEST] which seems to work?
Subject: Re: [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC rsandifo at gcc dot gnu dot org writes: > OK, I'm going to need some help debugging this one. First of all, > how are you running your tests? E.g. > > (a) are you using --target_board unix/-m64, > (b) is -m64 the default, or > (c) something else? I'm using --target_board 'unix{,-mabi=64}'. > Second, this: > > [find_libgcc_s $GCJ_UNDER_TEST] > > is supposed to return the directory of the 64-bit libgcc, but presumably > it isn't doing. Could you compare the result of that command with > something like: > > [find_libgcc_s $GFORTRAN_UNDER_TEST] > > which seems to work? I've tried running runtest manually both in gcc/testsuite/gfortran like this > runtest --tool gfortran --srcdir /vol/gcc/src/gcc-dist/gcc/tesuite --target_board 'unix{-m64}' -v which works correctly, and in sparc-sun-solaris2.11/libjava/testsuite like so > runtest INTERPRETER=yes --tool libjava --srcdir /vol/gcc/src/gcc-dist/libjava/testsuite --target_board 'unix{-m64}' -v which fails horribly: Expect binary is expect Using /vol/gnu/share/dejagnu/runtest.exp as main test driver Verbose level is 1 Login name is ro Found /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/site.exp Found /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/site.exp Using test sources in /vol/gcc/src/gcc-dist/libjava/testsuite Using test binaries in /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite Tool root directory is /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11 Using /vol/gnu/share/dejagnu to find libraries WARNING: Couldn't find the global config file. Loading /vol/gnu/share/dejagnu/utils.exp Loading /vol/gnu/share/dejagnu/framework.exp Loading /vol/gnu/share/dejagnu/debugger.exp Loading /vol/gnu/share/dejagnu/remote.exp Loading /vol/gnu/share/dejagnu/mondfe.exp Loading /vol/gnu/share/dejagnu/xsh.exp Loading /vol/gnu/share/dejagnu/telnet.exp Loading /vol/gnu/share/dejagnu/rlogin.exp Loading /vol/gnu/share/dejagnu/kermit.exp Loading /vol/gnu/share/dejagnu/tip.exp Loading /vol/gnu/share/dejagnu/rsh.exp Loading /vol/gnu/share/dejagnu/ftp.exp Loading /vol/gnu/share/dejagnu/target.exp Loading /vol/gnu/share/dejagnu/targetdb.exp Loading /vol/gnu/share/dejagnu/libgloss.exp Loading library file /vol/gcc/src/gcc-dist/libjava/testsuite/lib/libjava.exp Found /vol/gcc/src/gcc-dist/libjava/testsuite/../../gcc/testsuite/lib/target-libpath.exp Testing libjava Opening log files in . Test Run By ro on Thu Jul 9 22:03:41 2009 Native configuration is sparc-sun-solaris2.11 === libjava tests === setting trap for SIGTERM to terminated setting trap for SIGINT to interrupted by user setting trap for SIGQUIT to interrupted by user setting trap for SIGSEGV to segmentation violation dirlist is /vol/gnu/share/dejagnu/baseboards pushing config for build, name is galeras dirlist is /vol/gnu/share/dejagnu/baseboards pushing config for host, name is galeras target list is unix{-m64} Schedule of variations: unix/-m64 target is unix/-m64 Running target unix/-m64 dirlist is /vol/gnu/share/dejagnu/baseboards/galeras /vol/gnu/share/dejagnu/baseboards Using /vol/gnu/share/dejagnu/baseboards/unix.exp as board description file for target. Using /vol/gnu/share/dejagnu/config/unix.exp as generic interface file for target. Using /vol/gcc/src/gcc-dist/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Loading /vol/gnu/share/dejagnu/standard.exp pushing config for target, name is unix/-m64 Running /vol/gcc/src/gcc-dist/libjava/testsuite/libjava.cni/cni.exp ... version: 4.5.0 jar file is /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../libgcj-4.5.0.jar gcj: libgcj.spec: No such file or directory while executing "exec /vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/gcc/gcj -B/vol/gccsrc/obj/gcc-4.5.0-20090702/11-gcc/gcc/ --encoding=UTF-8 -m64 --print-multi-directory" ("eval" body line 1) invoked from within "eval exec $compiler [board_info target multilib_flags] --print-multi-directory" (procedure "find_libgcc_s" line 16) invoked from within "find_libgcc_s $GCJ_UNDER_TEST" (procedure "libjava_init" line 71) invoked from within "${tool}_init $test_file_name" invoked from within "if [info exists tool] { if { [info procs "${tool}_init"] != "" } { ${tool}_init $test_file_name } }" invoked from within "if [file exists $test_file_name] { set timestart [timestamp] if [info exists tool] { if { [info procs "${tool}_init"] != "" } { ${tool}_init..." (procedure "runtest" line 14) invoked from within "runtest $test_name" ("foreach" body line 42) invoked from within "foreach test_name [lsort [find ${dir} *.exp]] { if { ${test_name} == "" } { continue } # Ignore this one if asked to. if { ${ignore..." ("foreach" body line 54) invoked from within "foreach dir "${test_top_dirs}" { if { ${dir} != ${srcdir} } { # Ignore this directory if is a directory to be # ignored. if {[info..." ("foreach" body line 121) invoked from within "foreach pass $multipass { # multipass_name is set for `record_test' to use (see framework.exp). if { [lindex $pass 0] != "" } { set multipass_..." ("foreach" body line 51) invoked from within "foreach current_target $target_list { verbose "target is $current_target" set current_target_name $current_target set tlist [split $curren..." (file "/vol/gnu/share/dejagnu/runtest.exp" line 1625) Unfortunately, the same thing happens when I invoke runtest manually in the 20090522 tree where the 64-bit tests still worked correctly. What I find, though, are two different invocations of gcj (found with truss): * one like this /vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/ -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../ -v which finds libgcj.spec, and * another one like this /vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/ --encoding=UTF-8 -m64 --print-multi-directory which doesn't (and lacks the second -B above, since libgcj.spec is only located in the libjava tree). Maybe this helps to get this resolved? Thanks. Rainer
Subject: Bug 40699 Author: rsandifo Date: Sat Jul 11 06:10:49 2009 New Revision: 149508 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149508 Log: gcc/testsuite/ PR testsuite/40699 PR testsuite/40707 PR testsuite/40709 * lib/gcc-defs.exp, lib/target-libpath.exp, lib/objc.exp, lib/gfortran.exp, lib/g++.exp, lib/obj-c++.exp, lib/c-torture.exp, lib/gcc-dg.exp, lib/gnat.exp, g++.dg/compat/compat.exp, g++.dg/compat/struct-layout-1.exp: Revert 2009-06-30 commit. libstdc++-v3/ PR testsuite/40699 PR testsuite/40707 PR testsuite/40709 * testsuite/lib/libstdc++.exp: Revert 2009-06-30 commit. libjava/ PR testsuite/40699 PR testsuite/40707 PR testsuite/40709 * testsuite/lib/libjava.exp: Revert 2009-06-30 commit. libgomp/ PR testsuite/40699 PR testsuite/40707 PR testsuite/40709 * testsuite/lib/libgomp.exp: Revert 2009-07-02 and 2009-06-30 commits. * testsuite/libgomp.c/c.exp, testsuite/libgomp.c++/c++.exp, testsuite/libgomp.fortran/fortran.exp: Revert 2009-06-30 commits. libffi/ PR testsuite/40699 PR testsuite/40707 PR testsuite/40709 * testsuite/lib/libffi-dg.exp: Revert 2009-07-02, 2009-07-01 and 2009-06-30 commits. libmudflap/ PR testsuite/40699 PR testsuite/40707 PR testsuite/40709 * testsuite/lib/libmudflap.exp: Revert 2009-06-30 commit. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/compat.exp trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.exp trunk/gcc/testsuite/lib/c-torture.exp trunk/gcc/testsuite/lib/g++.exp trunk/gcc/testsuite/lib/gcc-defs.exp trunk/gcc/testsuite/lib/gcc-dg.exp trunk/gcc/testsuite/lib/gfortran.exp trunk/gcc/testsuite/lib/gnat.exp trunk/gcc/testsuite/lib/obj-c++.exp trunk/gcc/testsuite/lib/objc.exp trunk/gcc/testsuite/lib/target-libpath.exp trunk/libffi/ChangeLog trunk/libffi/testsuite/lib/libffi-dg.exp trunk/libgomp/ChangeLog trunk/libgomp/testsuite/lib/libgomp.exp trunk/libgomp/testsuite/libgomp.c++/c++.exp trunk/libgomp/testsuite/libgomp.c/c.exp trunk/libgomp/testsuite/libgomp.fortran/fortran.exp trunk/libjava/ChangeLog trunk/libjava/testsuite/lib/libjava.exp trunk/libmudflap/ChangeLog trunk/libmudflap/testsuite/lib/libmudflap.exp trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
"ro at techfak dot uni-bielefeld dot de" <gcc-bugzilla@gcc.gnu.org> writes: > Unfortunately, the same thing happens when I invoke runtest manually in the > 20090522 tree where the 64-bit tests still worked correctly. Ah! Thanks, that explains it. So the --print-multi-lib command failed before the patch too, but adding the directories for all multilibs masked this problem. (I was wrongly assuming it was the --print-multi-lib invocation itself that I'd broken.) > What I find, though, are two different invocations of gcj (found with truss): > > * one like this > > /vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj > -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/ > -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/sparc-sun-solaris2.11/libjava/testsuite/../ > -v > > which finds libgcj.spec, and > > * another one like this > > /vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/gcj > -B/vol/gccsrc/obj/gcc-4.5.0-20090522/11-gcc/gcc/ --encoding=UTF-8 -m64 > --print-multi-directory > > which doesn't (and lacks the second -B above, since libgcj.spec is only > located in the libjava tree). > > Maybe this helps to get this resolved? It does, thanks. I agree that the missing -B option is the problem here. However, the patch has already called a lot of fallout, so the best thing seemed to be to revert it. Thanks a lot for the help though: it shows what needs to be fixed if I or someone else comes back to this at a later date.