OS X 10.11.4 Dynamic Library Dependency Problem

[Sasha Kolesnikov]

@SGaist more information

[Sasha Kolesnikov]

@SGaist I I think this is should help

[SGaist]

Is it me or the QtMultimediaWidgets module wasn't listed ?

[Sasha Kolesnikov]

@SGaist My bad.Pic

[SGaist]

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]

@Sasha-Kolesnikov Build after deploy it is a bad idea. This is solution

[SGaist]

Do you mean that you re-built your application after calling madecployqt ?

[Sasha Kolesnikov]

@SGaist Yes

[SGaist]

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.

[jonawebb]

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:

1. 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).
2. 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.