[Bug testsuite/40699] [4.5 Regression] All sparcv9 libjava execution tests fail on Solaris 11/SPARC

["rsandifo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #7 from rsandifo at gcc dot gnu dot org  2009-07-11 06:44 -------
"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.


-- 

rsandifo at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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