Deploying Qt apps on OS X El Capitan that link against 3rd party library

FigBug

I 'm trying to deploy a Qt app using El Capitan that used to work on previous version of OS X.

In my .pro file I link against the library:
LIBS += -L/Users/rrabien/dev/main/raceman/libxl_mac/lib -lxl

When I run macdeployqt I get:
ERROR: no file at "/usr/lib/libxl.dylib"

I used to copy the dylib to /usr/lib, but I can no longer do that with El Capitan (even using sudo)

Any idea how to get the app to deploy?

SGaist

Hi and welcome to devnet,

You can use install_name_tool to update the id of the library to match its new path.

iszakine

I have seen this issue several times before and with several versions of the Qt 5 series. At one point I wondered whether it had something to do with the pre-canned Qt libraries and tools. I used to compiled Qt from source, but at one point thought that installing from the binary packages could speed up the process of upgrading the Qt ecosystem every so often (in retrospective, a bad move).

Out of curiosity, however, I dived in and went back to my old ways of simply building the whole framework from the source package. To my surprise, everything seems to work out of the box as it used to, with none of that @rpath and @application_path nonsense at all.

Botton line: if you have seen issues with macdeployqt et al., then perhaps compiling and installing Qt from source might solve the problem entirely.

One note: if you need QtScript then you will need to get it installed by going into the "qtscript" directory and issuing the extra command: "make module-qtscript && make install".

For me the procedure above eliminated all the issues with macdeployqt so far.

I hope the above helps someone else having similar issues.

iszakine

Just an addendum in case someone else decides to go the route I attempted to describe above for Mac 10.11 (El Capitan). In that case, you will most probably end up frustrated after hitting compilation issues with QtWebEngine et al. (it refuses to compile out of the box). I have come across the following issues and went over them as explained below:

a) You will need to patch "qtwebengine/src/3rdparty/chromium/tools/gyp/pylib/gyp/xcode_emulation.py" with the following:

sdk_root = self._SdkPath(config_name)
if not sdk_root:
sdk_root = ''
----> return l.replace('$(SDKROOT)', sdk_root) <---- Replaced this line with the following block (below).
library = l.replace('$(SDKROOT)', sdk_root)
if l.startswith('$(SDKROOT)'):
basename, ext = os.path.splitext(library)
if ext == '.dylib' and not os.path.exists(library):
tbd_library = basename + '.tbd'
if os.path.exists(tbd_library):
library = tbd_library
return library

To see the original post about this "patch" refer to:
https://trac.macports.org/attachment/ticket/49074/patch-chromium_tbd_libraries.diff

b) Missing links to several libraries needed by QtWebEngine et al. Create symlinks to the respective and already existing libraries:
sudo ln -s /usr/lib/libz.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libz.dylib

sudo ln -s /usr/lib/libresolv.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libresolv.dylib

sudo ln -s /usr/lib/libbsm.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libbsm.dylib

sudo ln -s /usr/lib/libcups.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libcups.dylib

For the details on the above refer to the discussion about it here:

https://trac.macports.org/ticket/49074

Following the flow above I successfully compiled, linked, and installed the Qt-5.5.1 libraries, as well as QtCreator 3.5.1 after that (also from source). So far, everything seems to work fine...