Until now I've always been using my own built Qt packages when building KDE packages for maemo. Initially because the Qt packages in extras-devel where missing some vital parts for KDE (mainly SSL support I think) but after that because I just had them installed, and it worked. But now I wanted to change this, and use the extras-devel provided Qt, as in theory that shouldn't matter, after all they are build from the same sources, with nearly identical configuration. As it turned out, this was actually quite a bit harder than I thought it would be.
As turns out, the current Qt packages are built with vfp support (which is a good thing, as it should make floating point computations quite a bit faster), but the default qemu version being used in scratchbox does not support vfp. Fortunately scratchbox also includes a newer 'cvs-m' version of qemu, that does support vfp, so I though I'd just use that instead. However that provided another unpleasant surprise, namely cmake doesn't work (correctly) in that version of qemu. I'm not sure what the exact problem is, but in some cases cmake failed to generate some files either during configuration or installation of a project.
One possible solution I first tried is to use the 0.8.2 qemu for running cmake and the csv-m version for running everything else. The difficulty with that approach is that you somehow have to make cmake (which is run in one version of qemu) run sub-processes that are run in a different version of qemu. As you might imagine, that didn't really work out as well as I hoped. So I was back to trying to find a version of qemu that is both capable of running cmake and vfp enabled applications. I first tried a 0.9.2 version I got from Jonas Hurrelmann, but that version didn't work either.
Jonas than suggested I tried compiling a newer svn version of qemu from qemu-arm-eabi.wiki.sourceforge.net. With that version of qemu I finally managed to get both a functioning cmake and function vfp/qt-tools. This isn't the end of this story though, as with this qemu version at unpredictable times automoc will just stop responding. While this isn't a very big problem to manually build stuff (you can just restart the build and continue where it failed when it hangs), it is quite anoying when trying to automatically build kde packages, as it is very hard to automatically detect qemu/automoc no longer making any progress; so for now I'm mostly back to manually building stuff... One possible solution would be to not use qemu, but use sbrsh and run the ARM binaries on a real ARM processor, although I fear that might make building stuff quite a lot slower.