ia64 libjava java-signal.h build failure

[Mark Mitchell]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

    Alexandre> the rest of the development snapshot.  I'm all for
    Alexandre> re-enabling it by default.

    Mark> I'm not.  It's just too risky at this point.

    Tom> What do you mean?  What is the risk?

We are talking about introducing new, major functionality.  

That always carries risks.

Look at the risks of much smaller changes:

  - I fixed a bug in the loop optimizer, but thereby exposed 
    another one, breaking the bootstrap on the ARM.
  
  - Zack simplified some code, only to break the bootstrap on
    UnixWare.

If we turn on Java, we're talking about activating lots of Makefiles,
lots of configury goo, lots of libtool goo, and forcing the C++
compiler to compile lots of complex library code.  

I don't want us tracking down these kinds of problems at this point.
Our job is to fix high-priority bugs and make a tarball.  That's it.

Users who want this functionality, and distributors, can turn this
functionality on, but I do not want to do this at this point in the
release cycle.  It is already on by default on the mainline, so we are
sure to have this in GCC 3.1.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com