GCJ for MinGW

I have updated my article "Building GCJ for Windows" and the associated scripts to work with the current SVN mainline sources of GCC (to be released as GCC 4.2). They might also work with GCC 4.1 sources, but I have not checked it myself. The article also has some tips for building GCC natively on Windows using the MSYS toolkit, especially to make the built and installed GCC relocatable (see below).

A major portion of the effort went in to ensure that the resultant toolchain was actually relocatable (that is, the installation can be archived and then extracted elsewhere, possibly on a different machine, and everything can still be expected to be working). The proper locations of the Windows headers and runtime libraries and the flags to pass to the GCC configuration scripts were something that took a lot of trial and error (and a lot of help from Mark Mitchell and Danny Smith) to get right, since I was trying to do something less common (building cross and crossed-native compilers) for a platform that gets the attention of very few GCC hackers as such, if at all.

I had stopped working on GCJ for Windows quite a while back and the reason I had to update my article and scripts was that there seemed to be a lot of people trying to build GCJ for Windows themselves using the latest released or in-trunk sources (and my instructions and scripts) and they were running into all sorts of issues. Unfortunately, GCJ on Windows has become worse than it used to be which is understandable since there is no one who is actively working on it to improve it. It is also a shame since even though it is a closed platform with an ugly design it appears to have the most number of users enthusiastically willing to try out GCJ.

We must do something about this situation.

QEMU
For a fan of Linux trying to make GCJ for Windows work, a very useful property of GCC is that it can be built on Linux as a cross compiler or as a crossed-native compiler targetting Windows. For a person with a relatively old machine and limited free time to hack on GCJ, this is also important since the build on Linux is way faster and far more reliable than that on Windows itself using MSYS. Equally important is the ability to test out the binaries created in this process without having to reboot the machine into Windows or having access over the network to another machine running Windows. Wine doesn't quite help since I need an environment that is as faithful to the real thing as possible.

QEMU running Windows on Linux comes to my rescue here. When run with the -kernel-kqemu option using the QEMU Accelerator ("kqemu"), the guest OS runs at very close to native speeds without adversely affecting the performance of the host OS. It has a built-in TFTP server that allows you to easily transfer files from the host machine into the guest system (there are also other ways of achieving this using QEMU, but this is the simplest). It's almost magical and is immensely useful. It's no wonder that virtualisation is becoming so popular these days and every developer who has tried it out sings its praises. If you are an "enterprise software" developer, you should already know what I am talking about. If you haven't tried it out yet, you really should. Virtualisation offers you the freedom and the flexibility to play around that is very useful and quite addictive.

Tweet