Cannot deploy Qt applications with MacPorts port qt4-mac

[clemens.brunner@…]

When I build my Qt app with the MacPorts version of Qt (qt4-mac), I get the following error when running macdeployqt on the application bundle:

ERROR: "install_name_tool: changing install names or rpaths can't be redone for: sigviewer.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
"
ERROR: ""
ERROR: "install_name_tool: changing install names or rpaths can't be redone for: sigviewer.app/Contents/Frameworks//libtiff.5.dylib (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)
"
ERROR: ""

Now I don't know why qt4-mac depends on tiff, but this seems to be causing the error. The official Qt binary does not have this problem, everything works fine with the official version.

I noticed this problem when I wanted to build my app on 10.8, but deploy it on 10.6. On 10.6, my app crashed immediately, even though I had all Qt switches necessary to deploy on older targets set correctly.

In summary, I think this should be a high priority bug because you cannot create working app bundles with the current port.

[cooljeanius (Eric Gallager)]

I think this should be a high priority bug

That's for the MacPorts team to decide. It's usually reserved for security vulnerabilities.

[cooljeanius (Eric Gallager)]

Cc Me!

[mf2k (Frank Schima)]

In the future, please Cc the port maintainer(s).

[michaelld (Michael Dickens)]

What is the command-line you are using to invoke macdeployqt, which results in those errors? I'd like to be able to replicate the error on my system so that I'm not trying to fix it blind. I do not use macdeployqt, so you'll need to be specific in describing what you did to get the error so that I can replicate it.

[clemens.brunner@…]

OK. Here are the steps to reproduce this problem:

1. sudo port install qt4-mac qt4-creator-mac
2. Download ​SigViewer source and ​external dependencies
3. Extract the source and the external dependencies; copy the "external" folder into the source folder (overwriting any folders if they exist)
4. Open sigviewer.pro with Qt Creator (make sure that the Qt SDK is correctly recognized, otherwise set it manually)
5. Select the release build (uncheck the debug build), and build inside the source folder (/path/to/sigviewer-0.5.2-src)
6. Build the project
7. In a terminal inside /path/to/sigviewer-0.5.2-src, enter: macdeployqt bin/release/sigviewer.app -dmg
8. Notice the error I described above
9. Deploy on Mac OS X 10.6 and notice the immediate crash after starting the app
10. Repeat the steps above, but uninstall the MacPorts versions of all Qt packages; install official binaries instead -everything will work fine

[neverpanic (Clemens Lang)]

I'm regurlarly using MacPorts Qt to build a different app where this works fine. I'm not sure why it breaks for you, especially since MacPorts recently added -Wl,-headerpad_max_install_names to the default linker flags. You might want to try rebuilding tiff from source (sudo port -ns upgrade --force tiff) to check whether this fixes your problem.

As for the crash on 10.6, I can also reproduce that. I assume that's because the qt Portfile doesn't handle your value of macosx_deployment_target as set in macports.conf. You might want to open a separate bug report for that.

[clemens.brunner@…]

Thanks, rebuilding tiff from source did get rid of this error message; macdeployqt now works as expected.

However, as you suspected, the issue with 10.6 is a separate problem. I didn't even know about setting macosx_deployment_target in my macports.conf, so it is not set at all on my machine. Therefore, the minimum target version seems to be the version of my OS, which is 10.8. I didn't know that manually setting the minimum target when building my application had no effect. Do you think that's a MacPorts bug or expected behavior?

In any case, this bug can be closed since rebuilding tiff solved my problem. On a related note, it would be interesting to know why these situations are not handled automatically by MacPorts; if some flags were updated, shouldn't all my ports have been rebuilt to ensure consistent operation?

[neverpanic (Clemens Lang)]

Replying to clemens.brunner@…:

Thanks, rebuilding tiff from source did get rid of this error message; macdeployqt now works as expected.

We should really revbump tiff some time soon to fix this.

I didn't know that manually setting the minimum target when building my application had no effect. Do you think that's a MacPorts bug or expected behavior?

That's intended. MacPorts is not affected by any environment variables you have set by default. However, setting macosx_deployment_target doesn't work with all ports correctly either, so chances are setting it might not have any effect on qt4-mac.

On a related note, it would be interesting to know why these situations are not handled automatically by MacPorts; if some flags were updated, shouldn't all my ports have been rebuilt to ensure consistent operation?

It's a trade-off; the question is whether we should force all users to rebuild all ports because of a rather simple (and meaningless for most users) change. Also, we currently don't have a facility in place to trigger rebuilding all ports after a MacPorts update -- we only support this for OS upgrades. Rev-bumping all ports isn't enough to fix this, because some people might still use an older version of MacPorts.

[clemens.brunner@…]

Replying to cal@…:

That's intended. MacPorts is not affected by any environment variables you have set by default. However, setting macosx_deployment_target doesn't work with all ports correctly either, so chances are setting it might not have any effect on qt4-mac.

Also, I would want to set the deployment target to 10.5 only for qt4-mac and not for all other ports - everything else would be kind of silly.

In summary, to build apps that link qt4-mac, the port needs to be built with the appropriate deployment target, which might or might not work. Meh. Looks like the solution for now is to go with the official Qt binaries...

Thanks for the great support and quick response!

[michaelld (Michael Dickens)]

Is this ticket's issue still valid with the somewhat recent qt 4.8.7 update? Does anybody care about this issue any longer?

[neverpanic (Clemens Lang)]

Original reporter has lost interest.