SWT Crash Problem with MingW/GCJ (UPDATED)

[Ranjit Mathew]

> Ranjit: on your website, you had mentioned having had a go at this and
running
> into problems. To your knowledge, was MSYS the culprit or the MINGW
runtime?

At the time I tried it, MSYS 1.0.7 on NT/2K could easily bootstrap GCC
(C/C++).
However, the GCJ build used to create problems since it resulted in too
many spawned processes that used to wake up some nasty crawlies in the
MSYS code. ;-)

Old timers of this list would remember that I posted kludgy workarounds for
this - for example, see this thread:

    http://gcc.gnu.org/ml/java/2002-08/msg00163.html

On Win98, MSYS's problems were exacerbated to a great extent, not helped
much
I think by the flaky nature or the "OS" itself. The MSYS/Win98 combo was
also
quite slow compared to the same task on Linux.

In recent times, Earnie Boyd (the primary MSYS maintainer) has been
aggressively fixing these problems, and the recent 1.0.9 snapshots seem
to have solved a few of the main irritants - this is why I am hopeful
(though not certain) of a native build on Windows/MSYS.


> I'm running into case sensitivity problems which to my untrained eye, seem
to
> occur when the compilation of a file triggers the compilation of a
dependent
> class.

This is an issue that is still present in GCJ 3.3. For example, the
following
test case easily illustrates the problem (try it out with your GCJ 3.3):

--- File: Foo.java --------------------------------------------------
public class Foo { }
---------------------------------------------------------------------

--- File: foo/Bar.java ----------------------------------------------
package foo;

public class Bar { }
---------------------------------------------------------------------

If you try to compile the class foo.Bar (*before compiling Foo* - note
that they do not depend on each other):
---------------------------------------------------------------------
C:\TEMP>gcj -C foo\Bar.java
.\foo.java:1: error: Public class `Foo' must be defined in a file called
`Foo.ja
va'.
   public class Foo {
                ^
1 error
---------------------------------------------------------------------

If you now compile Foo and *then* try to compile foo.Bar:
---------------------------------------------------------------------
C:\TEMP>gcj -C Foo.java

C:\TEMP>gcj -C foo\Bar.java
Foo.java: In class `foo.Bar':
Foo.java: In constructor `()':
Foo.java:0: fatal error: reading class Foo for the second time from
.\foo.class
compilation terminated.
---------------------------------------------------------------------

And in all likelihood, these are the same errors that you'd be seeing
in your native build.

For "real world" examples of these see (pkg v/s class):

java.awt.color v/s java.awt.Color
java.awt.event v/s java.awt.Event
etc.

Apart from the MSYS related problems, this was the major reason for build
failures in my early attempts:

    http://gcc.gnu.org/ml/java/2002-09/msg00073.html

I bypassed these simply by leaving out all the AWT classes since AWT didn't
work (at that time) anyways.

With Linux builds, I didn't face any of these issues and so didn't have
to resort to these kludges.

Ranjit.