This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Target library disabling at toplevel
- From: NightStrike <nightstrike at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, gcc at gcc dot gnu dot org, java at gcc dot gnu dot org, hp at axis dot com, hp at bitrange dot com
- Date: Wed, 23 Mar 2011 07:48:42 -0400
- Subject: Re: Target library disabling at toplevel
- References: <Pine.LNX.4.64.1103221942200.9686@digraph.polyomino.org.uk> <mcrlj06reqg.fsf@google.com>
On Tue, Mar 22, 2011 at 6:07 PM, Ian Lance Taylor <iant@google.com> wrote:
> "Joseph S. Myers" <joseph@codesourcery.com> writes:
>
>> Why do a great many targets disable libgcj by default in the toplevel
>> configure.ac?
>
> I believe that it's just a hack: libgcj doesn't build on the target, but
> gcc/java does. ?Disabling libgcj lets the gcc configure/make complete in
> a natural way.
>
> unsupported_languages is a clearly superior approach, but it postdates
> many of the cases in which libgcj is added to noconfigdirs.
In some cases, like for x86_64-w64-mingw (Win64), we can build gcj
fine, and we intend to support a java compiler. However, at present,
we cannot build libgcj because the boehm-gc in the tree is several
years out of date. Once Hans, or someone else with enough skill,
updates that, we can turn on libgcj. Until then, we'd like to make
sure that building the compiler doesn't break.
Given how out of date certain dependencies are for libgcj, I would not
be surprised if other targets suffered the same fate.