This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: ia64 libjava java-signal.h build failure
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: ia64 libjava java-signal.h build failure
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Sun, 22 Apr 2001 19:38:56 +1200
- Cc: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, Mark Mitchell <mark at codesourcery dot com>, jsturm at one-point dot com, gcc-bugs at gcc dot gnu dot org, java at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
On Sunday, April 22, 2001, at 05:51 PM, Alexandre Oliva wrote:
> Please look at configure.in again. ${libgcj} appears in noconfigdirs
> of lots and lots of platforms. Enabling the Java language by default
> will result in libjava not being built on such platforms.
I'm aware of what configure.in does. This is what I think it should do.
Rather that unconditionally disabling libgcj on a given target, it
should instead specify a default set of arguments for the
--enable-languages option.
> It is
> indeed not disabled for Irix 6 nor Cygwin; perhaps because there's
> some hope that it will work on those platforms?
Right - there is some hope of libgcj working on most platforms, its just
that nobody tests them often enough for us to be able to say that they
definitely work. Irix is an interesting case because it does seem to
work for some people but not others (due to the link command line length
thing, which we never quite solved) on seemingly the same OS. Perhaps
due to different patch levels of Irix or something. In this case it
would be best to disable by default, but make it easy to enable with an
explicit "--enable-languages=java" which would override any default
setting in the configure.in. Specifying one command line option to all
of java seems a lot less painful to me that having to mess around with
configure.in all the time.
And, if we are going to enable java by default then we really need
"--enable-threads" and possibly "--enable-shared" by default also. If we
don't or can't do that, then I think its actually good that we require
--enable-languages in order to draw attention to the need for these
additional arguments.
regards
[ bryce ]