GCJ/minGW produced executables and linux/wine

Jeff Sturm jsturm@one-point.com
Tue Mar 4 18:51:00 GMT 2003

On Tue, 4 Mar 2003, Ranjit Mathew wrote:
> > > "--enable-sjlj-exceptions" explicitly during GCC configuration, it
> > > builds as a DWARF-2 EH using target.
> >
> > Hmm... that's not what I observe.  Not on the 3.3 branch at least.
> Yes, once again, I confused the effects of mingw-local patches v/s
> vanilla GCC 3.3. Sorry.

Ugh.  How is it that mingw always has some outstanding patch set that
never quite gets integrated into GCC?  (Don't answer that, I don't
really want to know...)

I think this test isn't quite right:

if test $can_unwind_signal = no && test $enable_sjlj_exceptions = no; then

since it gives no assurances that signal handling a.k.a. exception filters
work at all.

I re-ran the testsuite with -fcheck-references.  It looks much better:

        === libjava Summary ===

# of expected passes        2297
# of unexpected failures    20
# of expected failures      16
# of untested testcases     27

If you agree that something like this should be in 3.3 (unless exception
handling is fixed), I'll prepare a patch.

Many of the remaining failures are caused by:

_Jv_ThreadInterrupt (_Jv_Thread_t *data)
  MessageBox(NULL, "Unimplemented", "win32-threads.cc:_Jv_ThreadInterrupt", MB_O  // FIXME:

which also causes my testsuite to hang waiting for mouse clicks :-(

If these and gctest can get fixed somehow, I'd say mingw-gcj looks good
for the 3.3 release (what is the timeframe, again?)  Otherwise,
status.html could be amended to say something more helpful than "Is


More information about the Java mailing list