From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30785 invoked by alias); 30 Mar 2002 22:56:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 30769 invoked by uid 71); 30 Mar 2002 22:56:01 -0000 Date: Sat, 30 Mar 2002 14:56:00 -0000 Message-ID: <20020330225601.30768.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Tom Tromey Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failures with -m64 Reply-To: Tom Tromey X-SW-Source: 2002-03/txt/msg01270.txt.bz2 List-Id: The following reply was made to PR java/6092; it has been noted by GNATS. From: Tom Tromey To: "Kaveh R. Ghazi" Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failures with -m64 Date: 30 Mar 2002 15:54:50 -0700 Kaveh> spawn [open ...] Kaveh> 7 file6 Kaveh> close result is child killed: illegal instruction Thanks. Kaveh> (I don't know what the "7 file6" means.) It is dejagnu debugging output. You can ignore it. Kaveh> Hmm, actually it *does* remove the FAILed executables. Well, Kaveh> let's see, I was running several passes and the -m64 pass goes Kaveh> first. I guess the subsequent passes without -m64 PASSed these Kaveh> tests and removed the executable. :-) Ah, yes. Sorry about that. Kaveh> That seems ok. So I ran it and got: Kaveh> Abort (core dumped) Ok. Often symptoms like this will mean some pretty low-level problem, like binutils failure or some basic problem with the port. Kaveh> If you'd like me to attempt anything else let me know. Kaveh> Alternatively, you could get a solaris2 box and run make check Kaveh> with: setenv RUNTESTFLAGS "--verbose Kaveh> --target_board='unix{-m64,}'" to get both regular and -m64 Kaveh> passes. I finally read about -m64 in the manual. It sets the pointer size to 64 bits. I think you would have to build the entire runtime with -m64 for this to even have a chance of working. For instance, "hello world" with gcj needs a virtual method call. If the hello program and the runtime disagree on pointer size, this is going to fail. Is there some mitigating factor I'm unaware of? I'm inclined to say that this isn't really a bug, and that you must make a -m64 multilib if you want that to work. Tom