Grig for Windows – This Time Working!

I have previously built native windows versions of grig using the DevCpp environment. The result was a limited success since the resulting application only worked with the dummy backend.

Later on, I have built a windows version of Gpredict using the MinGW and MSys packages. This build was performed on windows and described in this article entry. Unfortunately, this method did not work out for gpredict-0.7.0  Frown

Thus, there was a need for new windows build infrastructure and I have decided to go and try cross-compilation. Now, gpredict is fairly complex so I decided to try grig first, since it is much simpler (I don’t have to build any DLLs).

Of course, I started out with Allin Cottrell’s Cross-Gtk+ publication, despite the fact that it is slightly out-dated. The basic idea, however, is still good and I used the win32 build infrastructure from his Gretl software as a basis for grig.

First, I created the baseline by downloading the win32api package from MinGW and the Gtk+ packages from Tor’s website (link no longer valid, but try this). This time I was paying attention only to download the absolutely necessary packages that are needed by a Gtk+ application. Which ones are needed is pretty obvious if you read the descriptions on Tor’s page. For example, I skipped libtiff and libjpeg since grig only needs PNG support at the moment.

I unpacked the zips into a directory called rte and the dev-zips into a directory called buildenv. I have also unpacked the pkg-config .pc files in order to attempt using Linux pkg-config with these specific directories. The contents of the win32api zip went, of course, to the buildenv directory.

Now, the .pc files in the Gtk+/GLib zips have a hardcoded windows path in them and this is no good. I have replaced them with the correct paths for my buildenv. I did this manually since the script on Allin’s page does not work with the current releases; the current .pc files have different directories for each package.

Once the build and run-time environments were in place, I created a Makefile based on the gretl Makefile. Mostly, I had to strip things away since gretl has lots of DLLs and plugins, while grig is one single target EXE. Then I had several trial-and-error iterations until the compilation of the source files went through without any errors. One of the most peculiar issues in this context was that I couldn’t re-use Allin’s hack by executing pkg-config from the Makefile wrapped into a ($shell …) statement. I had to do it with the exec-quotes and thus also specify the PKG_CONFIG_PATH environment before invoking make. However, this was only the case for CFLAGS vars, not for LIBS. Go figure…

Ok, so compilation went through, but linking against hamlib did fail with:

grig-debug.o:grig-debug.c:(.text+0x179): undefined reference to __imp__rig_set_debug_callback 
grig-debug.o:grig-debug.c:(.text+0x18f): undefined reference to __imp__rig_set_debug_callback 
grig-debug.o:grig-debug.c:(.text+0x277): undefined reference to __imp__rig_set_debug
...

– and a lot more for every single API call.

Here I had no idea what was going on. I tried to google, I tried the hamlib-stdcal package, different linking options, still no luck. Then, using i586-mingw32msvc-nm I found that these symbols were available in libhamlib-2.lib, but my build process tried to link against hamlib.dll.a, which apparently did not have these symbols.

So, where to go from here? Well, I tried to explicitly specify libhamlib-2.lib as if it was a .o file instead of the -lhamlib option (which takes the hamlib.dll.a) and – believe it or not – I ended up with grig.exe.!

Now on to testing…
I created a dist directory containing a copy of rte + the stuff coming from grig: bin/grig.exe share/pixmaps/grig/*.png and the manual page converted to HTML into doc/grig.html. I also included the misc info files like AUTHORS, COPYING, ChageLog, etc. I scp’d the dist directory over to my laptop running WinXP and voila, executing grig.exe brought up grig running with the dummy backend.

One good question concerning the testing of grig was how to specify the device name, i.e. /dev/ttyUSB0 in Linux. The device name of the use2serial adapter was COM7 and I simply specified -r COM7 on the command line: It worked!

I also created a grig.ico based on the Linux icon. I simply copied the method used in gretl for this. It gets automatically embedded into the EXE 🙂

Although grig was working fine, the Gtk+ theme didn’t really look like the gtk-wimp I have used for gpredict. I found out that it was missing from the dist, but hey wait… checking on the web page I learned that gtk-wimp is now included in Gtk+ under the name MS-Windows. Ok, so I transferred it but still no luck. Grig kept on using the Raleigh or whatever theme. So I simply decided to copy the MS-Windows gtkrc over to the Raleigh directory and exclude all other gtkrc files. Grig now looked like a normal windows application.

I packaged up the dist and released it on SourceForge. Tomorrow, the adventure will continue with gpredict.