public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failures with -m64 Date: Sat, 30 Mar 2002 14:56:00 -0000 [thread overview] Message-ID: <20020330225601.30768.qmail@sources.redhat.com> (raw) The following reply was made to PR java/6092; it has been noted by GNATS. From: Tom Tromey <tromey@redhat.com> To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> 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
next reply other threads:[~2002-03-30 22:56 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-03-30 14:56 Tom Tromey [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-04-10 18:06 Tom Tromey 2002-03-30 22:06 Kaveh R. Ghazi 2002-03-30 21:46 Tom Tromey 2002-03-30 21:26 Kaveh R. Ghazi 2002-03-30 12:36 Kaveh R. Ghazi 2002-03-29 11:16 Tom Tromey 2002-03-29 11:06 Kaveh R. Ghazi 2002-03-29 8:56 Tom Tromey 2002-03-29 8:16 ghazi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020330225601.30768.qmail@sources.redhat.com \ --to=tromey@redhat.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).