Newer versions of Qt come with the nice and handy tool `macdeployqt` – I think it first appeared offically in 4.6. What this basically does is that it looks for linked Qt libraries and plugins in your binary file and copies the needed ones over to your application bundle, so your application is ready for distribution.
So far so good, this worked nicely with the [Carbon binaries](http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x) supplied by Nokia, but it stopped working properly with the Cocoa builds. While the latter are advertised as “…for Mac OS 10.5 – 10.6” and really let you build and run your application on 10.5 (yes, I still haven’t followed the crowd and updated), the `macdeployqt` does not. It depends on newer versions of `strip` and `install_name_tool` which only come with newer versions of Xcode, i.e. >= 3.2. And guess what… yes, Xcode 3.2 is of course not available on 10.6.
(Nokia has actually an older, already closed [bug report](http://bugreports.qt.nokia.com/browse/QTBUG-9318) on the issue, but I doubt they will fix the issue, they do not invest much anyways on non-mobile platforms these days and 10.7 is soon out as well, making 10.5 look even more deprecated…)
So at first I thought “lets try build a Cocoa distribution” for guitone, because I believed this could bring some speed and other improvements and I accepted that I had to kick 10.4 support out of the way for this to achieve, but this bug is actually a show stopper for me.
I’ll probably have to give away Mac packaging for guitone in the mid-term future anyways. I do not plan to upgrade to 10.7 nor to a complete new Mac (I don’t like the direction Apple is heading, but this is a different story) and Qt 4.8 will definitely no longer ship with Carbon support.