1

I've got C++ application which is using Qt, I'm building it with cmake and linking using following:

target_link_libraries(myApp Qt5::Widgets Qt5::OpenGL ...)

it works fine but when I'm trying to distribute it it's failing because of missing qt libraries.

I was trying to get libraries from my local qt installation Qt/5.4/clang_64/lib/QtCore.Framework/Versions/5/QtCore and other with similar paths and put them near myApp but it doesn't help. It's still trying to get those libraries from local qt installation and if I rename folder of local qt installation it fails.

How to distribute my applications which is using qt libraries on OSX/Mac?

cnd
  • 32,616
  • 62
  • 183
  • 313
  • 1
    Possible duplicate of [Deploy Qt application on MAC with Qt framework](http://stackoverflow.com/questions/7411677/deploy-qt-application-on-mac-with-qt-framework) – MrEricSir Oct 26 '15 at 15:50

2 Answers2

3

Qt 5.5 comes with a helper tool called macdeployqt. You can run it from the command line, it will produce a valid .app (or even a .dmg containing the app if you ask for it). It's fairly straightforward to use, there are only a few options (like creating a dmg output, using debug libraries...) if you depend only on Qt.

If you have more dependancies that are dynamically linked, then you'll probably need to embed them as well in the application bundle (the .app folder).

sansuiso
  • 9,259
  • 1
  • 40
  • 58
  • For the dependencies that `macdeployqt` doesn't account for, you can use CMake's [BundleUtilities](https://cmake.org/cmake/help/v3.3/module/BundleUtilities.html) module, which works for all platforms, not just Mac. The Windows equivalent of `macdeployqt` is `windeployqt`, but unfortunately there's not (yet) an equivalent `linuxdeployqt`. – Craig Scott Oct 27 '15 at 21:05
  • Will BundleUtilities take care of the `rpath` dance on Mac? – sansuiso Oct 27 '15 at 21:31
  • 1
    It does try to. Whether it handles rpath in the way you want/intend you'd have to check for yourself. Part of what BundleUtilities does is to copy into the bundle any external dependencies and then update the rpaths of the app executables and libraries to point to those copies. – Craig Scott Oct 28 '15 at 09:34
  • Oh thanks for the tip! It's actually doing what I meant. I will be able to remove some post-build scripts and cleanup my workflow then. – sansuiso Oct 28 '15 at 09:41
0

From the QT site:

But when you are deploying the application, your users may not have the Qt frameworks installed in the specified location. For that reason, you must either provide the frameworks in an agreed upon location, or store the frameworks in the bundle itself. Regardless of which solution you choose, you must make sure that the frameworks return the proper identification name for themselves, and that the application will look for these names. Luckily we can control this with the install_name_tool command-line tool.

The install_name_tool works in two modes, -id and -change. The -id mode is for libraries and frameworks, and allows us to specify a new identification name. We use the -change mode to change the paths in the application.

Let's test this out by copying the Qt frameworks into the Plug & Paint bundle. Looking at otool's output for the bundle, we can see that we must copy both the QtCore and QtGui frameworks into the bundle. We will assume that we are in the directory where we built the bundle.

mkdir plugandpaint.app/Contents/Frameworks cp -R /path/to/Qt/lib/QtCore.framework plugandpaint.app/Contents/Frameworks cp -R /path/to/Qt/lib/QtGui.framework plugandpaint.app/Contents/Frameworks

First we create a Frameworks directory inside the bundle. This follows the Mac OS X application convention. We then copy the frameworks into the new directory. Since frameworks contain symbolic links, and we want to preserve them, we use the -R option.

install_name_tool -id @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore plugandpaint.app/Contents/Frameworks/QtCore.framework/Versions/4.0/QtCore install_name_tool -id @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui plugandpaint.app/Contents/Frameworks/QtGui.framework/Versions/4.0/QtGui

Then we run install_name_tool to set the identification names for the frameworks. The first argument after -id is the new name, and the second argument is the framework which identification we wish to change. The text @executable_path is a special dyld variable telling dyld to start looking where the executable is located. The new names specifies that these frameworks will be located "one directory up and over" in the Frameworks directory.

install_name_tool -change path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore plugandpaint.app/Contents/MacOs/plugandpaint install_name_tool -change path/to/qt/lib/QtGui.framework/Versions/4.0/QtGui @executable_path/../Frameworks/QtGui.framework/Versions/4.0/QtGui plugandpaint.app/Contents/MacOs/plugandpaint

Now, the dynamic linker knows where to look for QtCore and QtGui. Then we must make the application aware of the library locations as well using install_name_tool's -change mode. This basically comes down to string replacement, to match the identification names that we set for the frameworks.

Finally, since the QtGui framework depends on QtCore, we must remember to change the reference for QtGui:

install_name_tool -change path/to/Qt/lib/QtCore.framework/Versions/4.0/QtCore @executable_path/../Frameworks/QtCore.framework/Versions/4.0/QtCore plugandpaint.app/Contents/Frameworks/QtGui.framework/Versions/4.0/QtGui After all this we can run otool again and see that the application will look in the right locations.

fatihk
  • 7,789
  • 1
  • 26
  • 48