Re: ia64 libjava java-signal.h build failure

[Alexandre Oliva <aoliva at redhat dot com>]

On Apr 22, 2001, Bryce McKinlay <bryce@albatross.co.nz> wrote:

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

--enable-languages is an option that affects the language front-ends
built by GCC (and, by side effect, and only recently, the target
libraries that depend on those front-ends).

But I agree we should have an option to let the user override the
decision of disabling some library, libgcj in particular, given how
widespread is its disabling.

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

Probably just because it's disabled by default.  I've recently started
enabling java on all platforms to see what gives.  Unfortunately, the
Irix boxen I've got access to used to be in a lab that was dismantled
last week, so I can't check how my tests went, nor whether libjava
would build with GCC 2.95.2.  But I have a feeling it did, because I
recall having done a little bit of porting work to get it working
around that time-frame.  So, Irix hopefully isn't going to be too hard
to put back in a working state.  I can't say anything about libjava on
Cygwin, though.

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

Oh, that problem.  Yes, it's possible that it still applies.  Despite
the new libtool option that was introduced to overcome it, we still
haven't started to make use of it.

> And, if we are going to enable java by default then we really need
> "--enable-threads" and possibly "--enable-shared" by default also.

It is my understanding that --enable-shared is the default now.  At
least, it is for libstdc++-v3 and libjava.  Not sure about libgcc.

--enable-threads was not necessary for libjava, last time I checked.
Of course, you'd get a threadless JVM, which is quite distant from a
regular JVM, but it has its uses.  I agree we should probably
--enable-threads by default, though.  But probably not for GCC 3.0.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me