public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> 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 22:06:00 -0000 [thread overview] Message-ID: <20020331060601.7665.qmail@sources.redhat.com> (raw) The following reply was made to PR java/6092; it has been noted by GNATS. From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> To: tromey@redhat.com Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/6092: sparc-sun-solaris2.7 has hundreds of libjava failures with -m64 Date: Sun, 31 Mar 2002 01:01:19 -0500 (EST) > From: Tom Tromey <tromey@redhat.com> > > >>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes: > > 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 assume I need a special 64 bit machine to do this. > I don't know whether I have access to one. Well, whatever sun box you have, I think you need to verify two things. One is that it must be running solaris2.7 or later for gcc to configure 64 bit. The second is that it must be the right hardware. If you run "uname -a" and get "sun4u" or run "prtconf" and get "UltraSPARC", you should be in good shape. I'm not an expert so other hardware may also suffice. Easiest thing is to try it and see what happens. You'll know that the -m64 stuff is working if the C tests look reasonable. Then try and see why the libjava ones choke. > Kaveh> No I think it's really a bug. If you look back, I specifically > Kaveh> showed the `ldd' results to prove I was using the correct > Kaveh> shared libs for 64-bit compilation. (The sparcv9 multilibs > Kaveh> *are* built with -m64.) > > Ok, thanks. I didn't know dejagnu knew about multilibs. > > As far as I know nobody has ever tried libgcj on a 64-bit Sparc box > before. It sounds like this requires actual debugging; I was hoping > it was some relatively simple thing. > Tom Heh, "actual debugging". :-) -- Kaveh R. Ghazi Director of Systems Architecture ghazi@caip.rutgers.edu Qwest Global Services
next reply other threads:[~2002-03-31 6:06 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-03-30 22:06 Kaveh R. Ghazi [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-04-10 18:06 Tom Tromey 2002-03-30 21:46 Tom Tromey 2002-03-30 21:26 Kaveh R. Ghazi 2002-03-30 14:56 Tom Tromey 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=20020331060601.7665.qmail@sources.redhat.com \ --to=ghazi@caip.rutgers.edu \ --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).