This is the mail archive of the
mailing list for the Java project.
Windows-native GCJ 3.2 (Alternate Approach)
- From: Ranjit Mathew <rmathew at hotmail dot com>
- To: java at gcc dot gnu dot org
- Date: Tue, 24 Sep 2002 10:13:08 +0530
- Subject: Windows-native GCJ 3.2 (Alternate Approach)
I have been able to find an alternative (and less painful)
approach to building a Windows-native GCJ from GCC 3.2 sources
using Linux as a build environment, in the following stages:
1. Build a Linux-hosted cross compiling GCC and binutils toolchain
containing the C, C++ and Java front-ends.
(i.e. build=host=i686-pc-linux-gnu, target=i686-pc-mingw32)
2. Use the cross compiler created above to create a Windows-native
(i.e. build=i686-pc-linux-gnu, host=target=i686-pc-mingw32)
This might seem utterly "Duh!" to you guys, but I'm absolutely
fascinated by the fact that it is at all possible!
This contrasts with the Windows-only approach I had posted
earlier (http://gcc.gnu.org/ml/java/2002-09/msg00072.html) - it
is far simpler (fewer changes needed to the GCC3.2 sources)
and far faster (the two stages *together* take *half* the time on
Linux v/s Win98 on the same box!). And there were no issues
with the problems related to case-insensitive filesystems this
The compiler thus created behaves similar to the earlier
Windows-native compiler, even in the problems it has (warnings
on "stabs debugging field description too long", no stack
traces from exceptions, etc.).
The only newer problems I faced during this exercise were:
a. The fastjar configure dies out finding the sizeof char in
Stage 2 above saying that it "can not run test while cross
compiling" - while it did not complain in Stage 1 above!
(IMO, Stage 1 is building a cross compiler while Stage 2
is either a Canadian cross or a native compiler - I'm not
too sure on the terminology.) I had to overcome this by
specifying "ac_cv_sizeof_char=1" in its configure script.
b. In Stage 2 above, the libgcj configure script picks up
the wrong fastjar, gcjh (but the right gcj from Stage 1).
I had to overcome this by explicitly specifying the values
for JAR, ZIP and GCJH on the make command line (with an "-e"
If anyone is interested, I'll post the mojo needed to get this