This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ia64 libjava java-signal.h build failure


Mark Mitchell wrote:

> >>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
>
>     Jeff> Unfortunately not many platforms seem to get testing with
>     Jeff> gcj.  That's a catch-22: they won't be widely tested until
>     Jeff> gcj builds by default.
>
> No, that's actually OK.
>
> There's supposed to be logic that turns off gcj where it's thought not
> to work.  It's OK if we simply test that logic.

While I agree with Mark's concerns about re-enabling the Java build,
I would very much like to see Java enabled by default in cases where we
know it is safe.

What I think needs to happen is that libgcj should be enabled by default
on platforms on which it should definitely work, like Linux, but can
still be disabled if desired (along with other languages) by specifying
an --enable-languages configure option. Likewise, it should be disabled
by default on platforms where we know it may have problems (like Irix or
win32), but can still be explicitly enabled with an --enable-languages
option for those who want to try their luck or hack on it. Currently, the
configurey doesn't work quite like this: the top-level configure.in needs
to be edited by the user to enable or disable it for a given platform.

The front-end itself should always be built unless java is disabled via
--enable-languages (not currently the case on the branch).

regards

  [ bryce ]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]