tags:

views:

50

answers:

1

I'm developing a Qt-based application and when I use macdeployqt on the bundle, the Qt plugins are not copied to the bundle.

However, if I run it a second time, they are. Additionally, "The svg icon plugin is deployed if the application uses the QtSvg module." is not fullfilled - my application does use QtSvg but the iconengines/* plugin is not copied.

I tried running it with -verbose=3, and the last couple lines are:

Log: Created configuration file: "silverlock.app/Contents/Resources/qt.conf" 
Log: This file sets the plugin search path to "silverlock.app/Contents/PlugIns" 

From what the last message says, it kind of seems that it intended to continue running, but didn't - almost as if it crashed.

Why is this happening? macdeployqt has worked for me before without issue.

Using:

  • Qt 4.6
  • Qt Creator 2.0
  • Leopard 10.5.8
+2  A: 

The problem lies at lines 355-365 of shared.cpp in the macdeployqt source:

while (frameworks.isEmpty() == false) {
    const FrameworkInfo framework = frameworks.takeFirst();
    copiedFrameworks.append(framework.frameworkName);

    // Get the qt path from one of the Qt frameworks;
    if (deploymenInfo.qtPath.isNull() && framework.frameworkName.contains("Qt") 
        && framework.frameworkDirectory.contains("/lib"))
    {
            deploymenInfo.qtPath = framework.frameworkDirectory;
            deploymenInfo.qtPath.chop(5); // remove "/lib/"
    }

The first framework/dylib name in your bundle that has "Qt" in its name is taken to determine the plugin path. Since the first framework/dylib name in my bundle was "QtSolutions_QtSingleApplication-2.6"... you get the picture. So I suppose a workaround is to rename the dylib to "qsa-2.6.dylib" or something.

In a nutshell: make sure your framework and library names don't have "Qt" in them or you'll run into issues with macdeployqt.

Hopefully this answer may help someone having the same issue.

Jake Petroules