Target library disabling at toplevel

Target library disabling at toplevel

[Joseph S. Myers]

Why do a great many targets disable libgcj by default in the toplevel 
configure.ac?

Where GCC provides a runtime library for a given language, I'd think the 
compiler isn't particularly useful without the library - and so if the 
compiler is built for that language, an attempt should be made to build 
the library, with a build failure if it isn't supported.  This is the 
situation with Go, for example - if you try to build with Go enabled for a 
target to which libgo hasn't yet been ported, you get a build failure in 
libgo telling you that the configuration you asked for isn't yet 
supported.

Thus, I'd think that the disabling of libgcj by default on many targets 
should be removed.  If it genuinely doesn't work on a given target, then 
the right setting is

    unsupported_languages="$unsupported_languages java"

though I'm not sure unsupported_languages works quite the right way (in my 
view, it should only disable inclusion of a language in 
--enable-languages=all; if you explicitly specify an unsupported language, 
it should still try to build it).  (And why (CC to maintainer) do some 
CRIS and MMIX targets list Fortran in unsupported languages?  I didn't 
think the Fortran libraries had any porting issues, unlike Java and Go and 
Ada.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target library disabling at toplevel

[Hans-Peter Nilsson]

> Date: Tue, 22 Mar 2011 19:51:38 +0000 (UTC)
> From: "Joseph S. Myers" <joseph@codesourcery.com>

> Why do a great many targets disable libgcj by default in the toplevel 
> configure.ac?

Maybe because the right way, through unsupported_languages,
never caught on and there never was a global conversion? :-)

> Where GCC provides a runtime library for a given language, I'd think the 
> compiler isn't particularly useful without the library - and so if the 
> compiler is built for that language, an attempt should be made to build 
> the library, with a build failure if it isn't supported.

Agreed, the library/language issue is why I added that variable
<http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00543.html>. :-)

>  (And why (CC to maintainer) do some

The archives are open, I had to search it myself, having forgot
all about this.

> CRIS

A closer inspection will show that it's only the subtarget
cris-*-aout.  IIRC support for this target was removed for GCC,
it'd probably be a good idea to do the same here at the
top-level for the other projects (newlib, binutils, gdb).  (For
the record, generating cris-aout output should still be possible
through cris-elf-objcopy.)

> and MMIX targets list Fortran in unsupported languages?  I didn't 
> think the Fortran libraries had any porting issues, unlike Java and Go and 
> Ada.)

For MMIX, the issues I mentioned at
<http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00572.html> are
presumably fixed, but pragmatically the interest level for
fortran on MMIX is ...undetectable.  (Prove me wrong: I
challenge anyone to send gcc-testresults@ with it enabled and
the mmixware simulator installed.)  So, for the time being I'm
not prepared to add that as something that is expected to be
maintained.

brgds, H-P

Re: Target library disabling at toplevel

[Joseph S. Myers]

On Tue, 22 Mar 2011, Hans-Peter Nilsson wrote:

> > CRIS
> 
> A closer inspection will show that it's only the subtarget
> cris-*-aout.  IIRC support for this target was removed for GCC,
> it'd probably be a good idea to do the same here at the
> top-level for the other projects (newlib, binutils, gdb).  (For
> the record, generating cris-aout output should still be possible
> through cris-elf-objcopy.)

I do intend as part of toplevel cleanup following up on removal of 
deprecated targets to cleanup such cases relating to targets removed from 
GCC (since whether or not any bit of the src repository supports them, 
GCC-specific configure code for them certainly isn't needed at toplevel).

> > and MMIX targets list Fortran in unsupported languages?  I didn't 
> > think the Fortran libraries had any porting issues, unlike Java and Go and 
> > Ada.)
> 
> For MMIX, the issues I mentioned at
> <http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00572.html> are
> presumably fixed, but pragmatically the interest level for

Those look like newlib-target issues, not MMIX-target issues, in any case.

> fortran on MMIX is ...undetectable.  (Prove me wrong: I
> challenge anyone to send gcc-testresults@ with it enabled and
> the mmixware simulator installed.)  So, for the time being I'm
> not prepared to add that as something that is expected to be
> maintained.

It's not a matter of "expected to be maintained", it's a matter of targets 
only being different from other targets where there is a clear reason for 
that difference (an important feature of the GNU toolchain is consistency 
between targets).  I expect most users of many targets to be using 
--enable-languages=c,c++ (or just c) - but I see no reason for the 
defaults for this target to be different from those for many other 
newlib-using targets.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Target library disabling at toplevel

[Ian Lance Taylor]

"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.

Ian

Re: Target library disabling at toplevel

[NightStrike]

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.

Re: Target library disabling at toplevel

[Richard Sandiford]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> (And why (CC to maintainer) do some CRIS and MMIX targets list Fortran
> in unsupported languages?  I didn't think the Fortran libraries had
> any porting issues, unlike Java and Go and Ada.)

For the record, builds with mipsisa64-elf fail with:

libgfortran/intrinsics/time_1.h:99:1: error: static declaration of ‘localtime_r’ follows non-static declaration
newlib/libc/include/time.h:61:12: note: previous declaration of ‘localtime_r’ was here

This is a long-standing problem.  It got stalled a while ago because of
a disagreement (in my eyes anyway) about how libgloss targets should be
handled.  We started down the path of using -T<target>.ld, so that they
could be treated like other targets.  But I preferred (and still prefer)
the idea of making libgfortran handle newlib in the same way as libstdc++,
or disabling libgfortran if we don't care.  I think Rask Ingemann
Lambertsen also had a patch that used a config.cache-style approach.

Richard

Re: Target library disabling at toplevel

[Paolo Bonzini]

On 03/22/2011 08:51 PM, Joseph S. Myers wrote:
> Why do a great many targets disable libgcj by default in the toplevel
> configure.ac?

Because that dates to before 2004, which IIRC is when toplevel 
configure.ac started looking at config-lang.in files.

Paolo