ia64 libjava java-signal.h build failure
Bryce McKinlay
bryce@albatross.co.nz
Sun Apr 22 00:38:00 GMT 2001
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 ]
More information about the Gcc-bugs
mailing list