SWT Crash Problem with MingW/GCJ (UPDATED)

[Mohan Embar]

Hi Erik (and whoever else is listening),

I'll try provide more detailed information. Bear in mind that this
is all new to me.

- I'm using WinXP Pro with all the latest service packs and critical
  updates. I'm using Eclipse 2.0.2 (swt-win32-2052.dll). I have a
  small C drive and a big D drive. C is the boot drive and WinXP
  is installed on D:, which is where I put basically everything,
  including MingW. My computer tower is facing west.
- I went to the MingW download page (http://www.mingw.org/download.shtml)
  and downloaded:
  
  - MinGW-2.0.0-3.exe
  - MSYS-1.0.8.exe
  - binutils-2.13.90-20021006-2.tar.gz
  - w32api-2.1.tar.gz
  - mingw-runtime-2.3.tar.gz
  
- I ran the MingW installer and installed to D:\MingW.
- I extracted binutils, w32api and mingw-runtime.
- I installed MSYS.
- I then built libswt.a as per http://gcc.gnu.org/ml/java/2002-12/msg00105.html
  In particular:
  
  - I created directory D:\Data\Programs\eclipse\native-swt
  - I took the build shell script and changed /c to /d. I could keep the
  rest intact because I'm using the same Eclipse version. I've attached this
  script (build.sh)
  - Since I don't like cluttering up my global environment, I made a batch
    file to set up the environment and invoke the build script (build.bat).
    I've attached this.
    
  The resultant libswt.a weighs 9203062 bytes and its MD5 checksum is:
  
  5be88b4933ae554f9be8c5db85ebeb74
  
- Now for the test programs. I created these in D:\temp\mingw and
  dropped to a WinNT command prompt (not an MSYS prompt).
- I used a simple batch file (btest.bat, attached) to build either
  test program. You invoke it using "btest Hello" or "btest Hello2".
- Hello.exe works. Hello2.exe doesn't as per my previous post. Also
  note that swt-win32-2052.dll is on my system path, but not in
  D:\temp\mingw, but this is okay because Hello.exe works. Note also
  that because of the setlocal/endlocal, D:\MingW\bin is no longer
  on my path when I run the executables, but I presume that this
  doesn't matter.
  
Here's another interesting variation. When I surround the run() call
by a try...catch block, the program works correctly and the contents
of the catch block are never executed! (Hello3.java, attached).

I'm assuming that since you got Hello2 to work, my configuration is
incorrect. The results are nevertheless surprising.

Thanks again for your time and patience.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.sh
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030207/b566b7fb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.bat
Type: application/octet-stream
Size: 75 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030207/b566b7fb/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: btest.bat
Type: application/octet-stream
Size: 180 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030207/b566b7fb/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hello3.java
Type: application/octet-stream
Size: 946 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030207/b566b7fb/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hello.java
Type: application/octet-stream
Size: 822 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030207/b566b7fb/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hello2.java
Type: application/octet-stream
Size: 811 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030207/b566b7fb/attachment-0005.obj>