Mohan (this-is-cool) 's snapshot gcc33-20030409

erik poupaert
Mon May 12 17:52:00 GMT 2003

Hi Ranjit

I've finally took my courage together to try to compile the swt native
support with mingw/gcc.

The first problem seems to be swt.h. It says:
#include "jni.h"

When I change that to:
#include <jni.h>

It fails to find jni.h in gcc/include, next to stuff like jvmpi.h,
symcat.h and what have you. So, I resort to copying jni.h to the folder
in which swt.h is located. Then it finds it. Is there a way to refer to
gcc/include/jni.h, without copying it?

A second problem, consists in missing symbols. I've downloaded
w32api-2.3.tar.gz from the mingw sourceforge repositories, and dumped it
over Mohan's gcc33-20030409 release candidate. So, I've got the latest
additions as well, I guess?

As usually callback.c compiles -- no sweat -- with gcj.I'm back,
however, to the old problem in structs.h. All .c files seem to refer to
it, and it fails to parse:

structs.h:776 parse error before '*' token
structs.h:776 parse error before OLECMD
structs.h:776 parse error before OLECMDTEST

I can see that particular header files will get included conditionally
only: initguid.h, aygshell.h, tpcshell.h and so on... Maybe VS.NET knows
how to go about these conditional includes, while gcc misses a point
left or right?

By the way, if gcc doesn't balk until line 776, that means that it has
recognized hundreds of symbols without a hick. I can see typical win32
stuff like setGUIDFields(...) that it parses without complaining. So,
kudos to the mingw32 people.

And then I got a series of cast warnings:
swt.c:436: warning: cast to pointer from integer of different size...
I guess I can happily ignore these warnings ... I hope?

Any suggestions?

More information about the Java mailing list