QT’s qmake

Geeezus. There’s a lot wrong with “make” in general and there’s been way too many attempts to fix it; no-one, as far as I can see, has got it right yet. qmake is no exception, but it does in fact manage to be particularly bad.

Firstly, the makefiles that qmake generates can’t do a “make DESTDIR=<whatever> install”, no, that’s too standardised, we couldn’t have that. You have to do a stupid “make INSTALL_ROOT=<whatever> install” instead (DESTDIR has some completely different and somewhat retarded meaning). And that, of course, doesn’t actually work, because the file paths in the makefile are written in such a way that it just doesn’t work. You can fix it by editing the “qmake.conf” file in the QT bundle and add “no_fixpath” at the end of the options listed for the CONFIG variable, before you run qmake. Why isn’t that the default? Considering that “fixing” the path actually borks it, I’m not sure what sort of numbnut came up with the term or the code.

It’s easy to verify this by trying to compile “qca” (QT cryptographic architecture) and installing it in some alternate location. If no_fixpath isn’t set, it doesn’t work, does it? Hello QT developers?

Oh yeah, and qmake has a very limited concept of quoting, but that’s certainly a problem not limited to this particular software package.


Edit: Apparently “no_fixpath” is no longer required in Qt 4.3.1; I’m not sure when it was fixed (it was a problem in 3.3.7). However INSTALL_ROOT is still used instead of (the de facto standard) DESTDIR.



Well as a product OO is not actually too bad, it’s just a nightmare to build the friggin’ thing. I mean would it be too hard to put together some coherent build documentation? The best that I have found so far is the page entitled “building open office under linux“. That page tells me I need the csh shell, but do I really? What is the –with-use-shell=bash option for then? It also tells me that I need to download and extract the “gpc” library in some directory, which also appears to be a lie as the build completed just fine without that. I pass the –disable-mozilla option to configure because I don’t want to have to deal with mozilla and it might reduce the size/duration of the build. I’m not sure what functionality I’ll miss out on; the documentation neglects to tell me that.

Upon running the “configure” script I am told that I need to either fetch a pre-built dll file and plonk it in some directory. Either that, or install mingw as a cross-compiler so that the dll can be built. WTF? This is linux I’m building on, why is a Windows dll needed? I can’t be stuffed installing mingw so I just grab the pre-built dll.

Continue reading

Grub vs Lilo

As a bootloader, lilo wins hands down. Here is why: Lilo is designed for a single job, and it does that well. Grub on the other hand understands (some) filesystems and a bunch of other stuff that a boot loader should know nothing about (like object file formats). Lilo is “generic”, that is, you can use it to boot off pretty much any filesystem. This is a great strength.

Among other things, that means if you use software RAID or LVM or a filesystem that Grub doesn’t understand, you can’t use Grub. Lilo more or less isn’t bothered by that stuff.

Grub’s understanding of the filesystem allows it to work after you move partitions around and that sort of thing, which is considered by some to make it superior. But with Lilo, all you have to do is re-run lilo after doing such changes and it will work just as well. What’s more, it’s smaller and it doesn’t care what filesystem you’re using.

Lilo is no bigger than it needs to be. Grub is. And normally you don’t need any of the extra features that Grub provides – if you do, it’s not doing its job. Lilo is a bootloader – it loads the operating system. Grub practically is an operating system.

Gigabyte BIOS

Ok, the first piece of crap software that I’m going to talk about is the BIOS on my Gigabyte “GA-8IPE775 Pro” motherboard.

What’s crap about this particular piece of software? Well, initially I didn’t think there was anything particularly crap about it, but I was wrong. See, the board has an onboard sound chip (AC’97) which isn’t particularly fancy but which can at least perform the basic task normally put to it, that is, to produce sound (which is actually transmitted down the cable plugged in to the speaker jack, you know how it goes).

However I wanted to use Skype* and what’s more I wanted the “ring” sound to come through the speakers whereas the voice (incoming and outgoing) to be handled via a headset. This required a second sound card to be installed to handle the headset – no wories, I happened to have a Creative sound card based on the ES1370 chip lying around (well, I think lazz might have given it to me at some point). So I plonked it in a spare PCI slot.

Upon booting up, I was slightly pissed off to discover that all trace of the onboard sound controller had disappeared. Windows device manager denied all knowledge and “lspci” under linux no longer showed the device at all. Bugger. It took me narely a minute to figure that the BIOS might be responsible, so I rebooted and went in to the BIOS setup. There you have all these nice options to disable onboard peripherals such as the IDE controller and, indeed, the audio controller. In fact, I noticed, there are two possible settings for the audio controller: “disabled” and “auto”. It was at this point that I began to get pissed off.

Basically, it emerged, the BIOS wasn’t going let me have the onboard sound as well as another sound card. Stupid, stupid, stupid. And crap.

Fortunately being one of those elite hacker types I was able to hack LILO to re-enable to onboard controller before booting the operating system, after downloading the chipset datasheet from Intel’s web site (good job Intel, very impressed by the level of documentation which is freely available).

So the end result is ok, but it would have saved me a lot of time if the BIOS had just had a third setting to allow me to enable the AC’97 regardless of whether another sound card was plugged in.

* Skype: Surely the topic of a future post