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.


   [ bryce ]

More information about the Gcc-bugs mailing list