* Target library disabling at toplevel
@ 2011-03-22 19:51 Joseph S. Myers
2011-03-22 21:50 ` Hans-Peter Nilsson
` (3 more replies)
0 siblings, 4 replies; 7+ messages in thread
From: Joseph S. Myers @ 2011-03-22 19:51 UTC (permalink / raw)
To: gcc, java; +Cc: hp, hp
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Target library disabling at toplevel
2011-03-22 19:51 Target library disabling at toplevel Joseph S. Myers
@ 2011-03-22 21:50 ` Hans-Peter Nilsson
2011-03-22 22:07 ` Joseph S. Myers
2011-03-22 22:07 ` Ian Lance Taylor
` (2 subsequent siblings)
3 siblings, 1 reply; 7+ messages in thread
From: Hans-Peter Nilsson @ 2011-03-22 21:50 UTC (permalink / raw)
To: joseph; +Cc: gcc, java, hp, hp
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Target library disabling at toplevel
2011-03-22 21:50 ` Hans-Peter Nilsson
@ 2011-03-22 22:07 ` Joseph S. Myers
0 siblings, 0 replies; 7+ messages in thread
From: Joseph S. Myers @ 2011-03-22 22:07 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gcc, java, hp, hp
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Target library disabling at toplevel
2011-03-22 19:51 Target library disabling at toplevel Joseph S. Myers
2011-03-22 21:50 ` Hans-Peter Nilsson
@ 2011-03-22 22:07 ` Ian Lance Taylor
2011-03-23 11:49 ` NightStrike
2011-03-23 11:24 ` Richard Sandiford
2011-03-23 16:51 ` Paolo Bonzini
3 siblings, 1 reply; 7+ messages in thread
From: Ian Lance Taylor @ 2011-03-22 22:07 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc, java, hp, hp
"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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Target library disabling at toplevel
2011-03-22 19:51 Target library disabling at toplevel Joseph S. Myers
2011-03-22 21:50 ` Hans-Peter Nilsson
2011-03-22 22:07 ` Ian Lance Taylor
@ 2011-03-23 11:24 ` Richard Sandiford
2011-03-23 16:51 ` Paolo Bonzini
3 siblings, 0 replies; 7+ messages in thread
From: Richard Sandiford @ 2011-03-23 11:24 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc, java, hp, hp
"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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Target library disabling at toplevel
2011-03-22 22:07 ` Ian Lance Taylor
@ 2011-03-23 11:49 ` NightStrike
0 siblings, 0 replies; 7+ messages in thread
From: NightStrike @ 2011-03-23 11:49 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Joseph S. Myers, gcc, java, hp, hp
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Target library disabling at toplevel
2011-03-22 19:51 Target library disabling at toplevel Joseph S. Myers
` (2 preceding siblings ...)
2011-03-23 11:24 ` Richard Sandiford
@ 2011-03-23 16:51 ` Paolo Bonzini
3 siblings, 0 replies; 7+ messages in thread
From: Paolo Bonzini @ 2011-03-23 16:51 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: gcc, java, hp, hp
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-03-23 16:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-22 19:51 Target library disabling at toplevel Joseph S. Myers
2011-03-22 21:50 ` Hans-Peter Nilsson
2011-03-22 22:07 ` Joseph S. Myers
2011-03-22 22:07 ` Ian Lance Taylor
2011-03-23 11:49 ` NightStrike
2011-03-23 11:24 ` Richard Sandiford
2011-03-23 16:51 ` Paolo Bonzini
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).