[CMake] CPack, fixup_bundle, macdeployqt, and QTBUG-5952

KC Jones kc.jones at skype.net
Wed Jan 5 21:28:26 EST 2011


Me again, with another issue:

On Mac, I'm running into the problem described in  QTBUG-5952: http://bugreports.qt.nokia.com/browse/QTBUG-5952 where my CPack generated D&D installer yields an installed app fails with a log message like "Qt internal error: qt_menu.nib could not be loaded."  This was also mentioned on this list in http://www.cmake.org/pipermail/cmake/2010-April/036438.html

The resolution in that thread was to copy qt_menu.nib into my bundle's resource directory.  Like the original developer on that prior thread, this feels wrong.  (And I can't yet make it work.)

I have noticed that if I manually run Qt's macdeployqt script on the app bundle built by my cmake target, there is no problem.  It does not copy the qt_menu.nib directory into ./Content/Resources - macdeployqt ends with the menu resources copied into ./Frameworks/QtGui.framework/Resources/qt_menu.nib

In other words, Qt's script which is sort of an equivalent to fixup_bundle in the sense that it rebases all the dynamic libraries, does something to resolve the references to the qt_menu.nib resources that fixup_bundle does not.  I have not reverse engineered the script to see what that is, but it generates a working bundle were fixup_bundle falls a bit short.

So I'm not sure what to do at this point.  Should I continue trying to copy qt_menu.nib into the bundle manually?  Should I attempt to run the macdeployqt script on the bundle instead of calling fixup_bundle??

This does seem like a bug in Qt4.7 - but it has also remained unfixed in Qt4.7.1, and macdeployqt does something magical, so holding my breath and waiting for a fix is not an option.  Ideas and suggestions welcome.


KC Jones
kc.jones at skype.net
SkypeId: bernalkc



More information about the CMake mailing list