Upgrading

In the process of building the libs I'm using, I've made several updates/upgrades/additions to my toolset. It didn't get out of control, but I felt the need to organize it properly, and to create a stable foundation.

So, I've been in upgrade mode. It all began with mingw, which I upgraded to gcc 4.7. Then, I've rebuilt the libs I've been using: Boost, libssh2 (and its OpenSSL and zlib dependencies), and Poco C++.

Ever since I installed a newer version of mingw (newer than the custom mingw that shipped with Qt Creator), I've found some hints that I might have trouble later on, especially where debugging is concerned. So, in order to see how well my proposed "stable foundation" worked, I created a simple C++ console program (called "Goooooooooood Morning, World"; yeah, I strive for originality), to test it.

As I hit "Debug", I got this wonderful message about how my debug process was having second thoughts about life and wasn't exactly in the mood to do its job at the moment, and could I please call back at a later time, etc, etc.

As a previous Borland tools user, the idea that command-line tools are being run when I click on a button on the IDE or select a menu item is still somewhat foreign. While this is not the case for some actions (e.g., building), because I was always aware of the command-line being there, other actions (say, debugging) have a less-than-obvious - to me - relation to the command-line. So, I've braced myself for a journey filled with the symbols of mysticism... er, I mean, debugging.

However, before I started, and with my head still full of potential incompatibility problems, I've figured if things went wrong I might have to rebuild Qt/Qt Creator with gcc 4.7; and, if that were the case, I might as well have an early start. So, while I was going through the debugger problem, I had a tail -f hapilly running in a DOS prompt on the build log, and I'm quite satisfied to say that both Qt and Qt Creator built successfully from source (which was another of the reasons why I did it - to see how it worked out).

Anyway... when I finally hit on the idea that the debugging process was actually a command-line execution, I went to my gdb-python27.exe and ran it (Qt Creator works with the python-enabled gdb). And it told me, in no uncertain terms, that it would absolutely refuse to do anything whatsoever until I got it on a date with python27.dll. Which led me to copy it to Qt Creator's debugging tools folder (which contains a copy of this DLL), and update its path in my toolchains.

Then, I had another go at debugging my "Goooooooooood Morning, World". And this time everything ran perfectly... except for the SIGILL, that is. Consulting an online dictionary, one could think the definition of SIGILL is "a seall or a signett". One would be wrong, though.

So, what was causing an illegal instruction? Google gave me no useful answers. After some time looking through Qt Creator's debugging tools docs, I found out about the debugging log, and fired another debugging session. When I got the error, I went to the log. And there was the first clue - my app was loading the wrong sdtlibc++ DLL. Why? Because the Run Settings for my project had Qt's paths before any other path (Qt's default behaviour). I wasn't entirely sure this was the cause, but I've changed it, anyway, because that was not the behaviour I wanted.

After this change, the debugging session ran perfectly. Then, I decided to up the ante, and add a QString (Qt's string class) to my example. After all, the Qt libs I'm using were built with Qt Creator's custom mingw and gcc 4.4. But, this time, everything went smoothly. No sign of the dreaded incompatibility.

So, for the time being, I'm declaring my current environment as "stable", and I'm hoping to keep it that way for a while.

Now, then... lessons learned:

• If an IDE action corresponds to a command-line program being run, open a shell and run it yourself. You may have to do some digging to find out if your IDE is passing any arguments to this program.
• Thoroughly investigate your IDE's debugging options and tools.
• Run your app from the IDE and from the OS (and, on Windows, use Process Explorer to see what it's loading). This is especially useful as the ultimate test for missing DLLs.
• If you have several toolchains (and, particularly, several versions of the same compiler), add to your build flags the option that prints version info. In my case, I added CFLAGS += -v. This way, I can look at the build output and check if the IDE is using the correct version.

Next steps:

• I'm taking a closer look at make, to see if I need to have it include more info on the output, and how might I do it. The --debug and -w options are a good start, but I was looking for something more akin to ksh's -x or -v options.
• I'll be taking some of Qt's examples for a building/running/debugging spin, to see if my environment is actually stable.

But, for now, back to my project.