Solved OS X 10.11.4 Dynamic Library Dependency Problem
-
-
-
Is it me or the QtMultimediaWidgets module wasn't listed ?
-
-
At first sight, it looks correct. Can you run
otool -l your_app.app/Contents/MacOS/exec_name
and look what you get for the rpath entries ? -
@Sasha-Kolesnikov Build after deploy it is a bad idea. This is solution
-
Do you mean that you re-built your application after calling madecployqt ?
-
@SGaist Yes
-
Indeed, that's not a good idea. Your application executable will be replaced nullifying the job done by
macdeployqt
. You'll have to call it again before re-releasing again your application. -
I've had similar problems with dynamic libraries in 10.11.4. The problems go away if I turn off System Integrity Protection.
These don't show up for every executable. It depends on where the executable is installed. My executable is a Safari extension, which has to be installed in /Library/Internet Plug-ins. Apparently, that (or running in Safari) makes the executable "protected."
I ran into two kinds of problems:- The executable used @rpath to load components of the Framework libraries (inserted into the package by macdeployqt). This doesn't appear to work with System Integrity Protection. @loader_path does work, as do absolute paths. (You can change the paths using install_name_tool).
- Qt loads plugins using dlopen. This doesn't appear to work at all with System Integrity Protection. As a result, the code fails in QtGuiApplication::createPlatformIntegration, which is where it tries to load the platform plugin.
I haven't found a workaround for the second problem. As a result it appears that Qt won't work for "protected" executables under OS X El Capitan.