------- Comment #7 from rsandifo at gcc dot gnu dot org 2009-07-11 06:44
-------
"ro at techfak dot uni-bielefeld dot de" <gcc-bugzi...@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
