Qt 5.5.1 OS X 10.11 Static linkage Qt Multimedia

[Tyras]

@kshegunov

I understand "static executable" (or, as Apple calls it, "static binary") as an executable file that requires no libraries other than those blunded by default with the OS.

I'll just take your word for it, since I have no basis for comparison. Note that I'm not so much arguing, as trying to understand "why" would that be. :)

Trust me, I'm still trying to understand why they did it this way.

[kshegunov]

@Tyras

I understand "static executable" (or, as Apple calls it, "static binary") as an executable file that requires no libraries other than those blunded by default with the OS.

I don't understand it like this. However I believe @Ivan-Kolesnikov is not linking the needed dynamic libraries from the OS X framework(s) - the foundation framework or however that is called ... he has to have LIBS += -lavfoundation or something along this lines in his application.

Edit:
Maybe something like:

LIBS += -framework AppKit -framework QuartzCore -framework QTKit

which I saw in a repo diff update somewhere.

Kind regards.

[SGaist]

Hi,

The symbols missing come from the Qt multimedia plugin based on AV Foundation. There are some special considerations for plugins when using Qt statically. These are described here.

On Windows you can have a fully static application. Microsoft does provide their runtime in both configurations but recommend to use the shared version to allow update to be done to them (as in security update). Going the full static way is possible but requires to modify Qt's mkspec to link against the static runtime and thus a full rebuild.

On OS X, it's indeed not possible to have 100% static application. You will always link dynamically to the system frameworks. Note that if you want to use the App Store, having a statically linked application is likely to get your application rejected. IIRC it's part of Apple's guideline to use dynamic libraries and framework.

So all in all, you can use a static Qt while still having dynamic dependencies.

On an important side note: static linking has licensing implications.

[kshegunov]

@SGaist said:

On Windows you can have a fully static application. Microsoft does provide their runtime in both configurations

This is news to me, but in any case I'm dynamic-linking enthusiast ...

On OS X, it's indeed not possible to have 100% static application. You will always link dynamically to the system frameworks.

So there's no problem as long as you link dynamically against the runtime, which is what I was trying to convince @Tyras. :)

[Tyras]

@kshegunov said

So there's no problem as long as you link dynamically against the runtime

Fair enough, I guess, but that can end up requiring the final user to install such runtimes in the target machine, or to bundle it with the application, what, IMHO, go against the purporse of static linking... but, if that suits the OP, or if the required runtimes are already present on the target, then you're right.

[SGaist]

What happens usually on Windows is that the runtime is bundled with the application. What can also be done is to run the Microsoft runtime installer as part of the installation of the application.

[kshegunov]

I, personally, would never consider linking statically the runtime, but that's just me. As it can be seen I was not even aware MS provides static binaries for the runtime ...

What can also be done is to run the Microsoft runtime installer as part of the installation of the application.

This always seemed to me as the best option on any platform, not only on windows.

[Tyras]

What can also be done is to run the Microsoft runtime installer as part of the installation of the application.

@kshegunov said:

This always seemed to me as the best option on any platform, not only on windows.

For applications meant to be installed, I agree completely. But, sometimes, for small applications meant to be run without installation from anywhere, is somewhat of a bother.

[Ivan Kolesnikov]

Thanks to Everyone for replies!

My main task is build this application in OS X and be able to run it in another OS X system without any Qt libraries. No need add this application to the App Store. If I build this application via Qt Creator without any static libraries then I can run executable file on this machine and it works fine, but if I move this executable file on a Mac without Qt then I getting the following error:
"dyld: Library not loaded: @rpath/QtMultimedia.framework/Versions/5/QtMultimedia
Referenced from: /Users/ivan/Downloads/Archive/./MetadataExtractor
Reason: image not found
Trace/BPT trap: 5"

@SGaist I think for solve this issue need only to create Qt Multimedia plugin statically as described here: http://doc.qt.io/qt-5/plugins-howto.html#creating-static-plugins
In Q_IMPORT_PLUGIN(PluginName) PluginName is multimedia.
In Q_INIT_RESOURCE(name) Name is a path to .qrc file for Qt Multimedia plugin
Is this correct ?

[SGaist]

In that case, why not just use macdeployqt to create the application bundle ?

[Ivan Kolesnikov]

I updated a .pro file to the following state:

QT += core multimedia widgets
QT -= gui
TARGET = MetadataExtractor
CONFIG += console
CONFIG += static
TEMPLATE = app
SOURCES += main.cpp
extractor.cpp
HEADERS +=
extractor.h

Then used the macdeployqt. This issue is resolved for me.
@SGaist @Tyras @kshegunov Thanks to Everyone!