Mohan (this-is-cool) 's snapshot gcc33-20030409
Mon May 12 10:04:00 GMT 2003
I've just upgraded from the 20030220 version to the 20030409 version. I
must say that I'm really pleased that the upper/lowercase bug that
prevented bytecode compilation has been fixed now. Nice work.
In the meanwhile, I've bumped into another issue with the snapshot.
I've created a little tool that produces bash shell scripts to compile
java sourcetrees with gcj. It works on linux. In order to avoid
dependencies on the jdk, it doesn't use "jar" to create jar files, but
A typical bash expression could be:
echo ' [script] jarring 48 class(es).'
zip -1 -q ../jar/com-mysql-jdbc-3-1-nightly-20030316.jar \
Now "zip" works fine on Linux. It also works fine on windows, but
unfortunately, it fails to work under bash/mingw32.
So, I downloaded the zip23 source, and tried to recompile it with the
20030409 gcc snapshot. All of this, in order to trace the commandline
argument processing located in zip.c and see what bash does differently
-- in supplying commandline arguments -- from the command.exe shell in
The compilation works fine up to the point where it starts processing
lib/gcc-lib/mingw32/3.3/include/limits.h. Then it says: syslimits.h "No
such file or directory". And indeed,limits.h does try to include -- in
the middle of undecypherable ifdefs -- a file "syslimits.h" which is not
present in the directory where limits.h is located itself.
Now, I could raise the issue with the mingw32 people, or with the gcc
people, or with the infozip people. I just hoped that someone on this
list could help. I'd like to get this out of the way, because I'd like
to concentrate on the the real work -- which is compiling the swt jni
support on windows with gcc, without resorting to VS.NET -- which
according to Ranjit, should now be possible. From there on, the whole
build process will be free of Microsoft or Sun dependencies.
More information about the Java