From: Tom Tromey <tromey@redhat.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org,
bonzini@gnu.org, dj@redhat.com, neroden@gcc.gnu.org,
aoliva@redhat.com, Ralf.Wildenhues@gmx.de,
green@redhat.com
Subject: Re: Toplevel cleanup: disable Java when libffi not supported
Date: Tue, 03 May 2011 15:16:00 -0000 [thread overview]
Message-ID: <m3d3jz3jd1.fsf@fleche.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1104292251310.20841@digraph.polyomino.org.uk> (Joseph S. Myers's message of "Fri, 29 Apr 2011 22:56:50 +0000 (UTC)")
>>>>> "Joseph" == Joseph S Myers <joseph@codesourcery.com> writes:
Joseph> arm*-elf are targets where libffi's configure thinks it is supported.
Thanks.
Joseph> So Java (and Go) should be disabled by default when libffi isn't
Joseph> supported, because they'd try by default to build libffi and so
Joseph> a default build will fail.
In the past, libffi could be disabled independently. This in itself
would not cause libjava to fail, because libjava accounts for this
possibility.
Since the only existing case where there was a libjava port without a
corresponding libffi port has gone away, I think it isn't very important
to try to support this. In the unlikely event that someone needs this,
they can come up with a new plan to handle it.
Tom
next prev parent reply other threads:[~2011-05-03 15:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-27 15:50 Toplevel cleanup: split out libgcj disabling Joseph S. Myers
2011-04-27 16:34 ` Toplevel cleanup: disable Java when libffi not supported Joseph S. Myers
2011-04-27 16:38 ` Andrew Haley
2011-04-28 6:34 ` Paolo Bonzini
2011-04-28 13:40 ` Joseph S. Myers
2011-04-28 16:18 ` Toplevel cleanup: reduce libgcj disabling Joseph S. Myers
2011-04-28 16:41 ` Paolo Bonzini
2011-04-29 16:26 ` Toplevel cleanup: disable Java when libffi not supported Tom Tromey
2011-04-29 22:57 ` Joseph S. Myers
2011-05-03 15:16 ` Tom Tromey [this message]
2011-04-27 17:31 ` Toplevel cleanup: split out libgcj disabling Mike Stump
2011-04-28 6:31 ` Paolo Bonzini
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=m3d3jz3jd1.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=Ralf.Wildenhues@gmx.de \
--cc=aoliva@redhat.com \
--cc=bonzini@gnu.org \
--cc=dj@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=green@redhat.com \
--cc=java-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=neroden@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: link
Be 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).