SWT Crash Problem with MingW/GCJ (UPDATED)

Ranjit Mathew rmathew4lists@hotmail.com
Tue Feb 18 08:44:00 GMT 2003

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

At the time I tried it, MSYS 1.0.7 on NT/2K could easily bootstrap GCC
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:


On Win98, MSYS's problems were exacerbated to a great extent, not helped
I think by the flaky nature or the "OS" itself. The MSYS/Win98 combo was
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
> occur when the compilation of a file triggers the compilation of a
> class.

This is an issue that is still present in GCJ 3.3. For example, the
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
   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
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

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


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.


More information about the Java mailing list