[Development] Qt 5.5.0 build issues on OS X : rpath

René J.V. Bertin rjvbertin at gmail.com
Sat Sep 12 12:43:57 CEST 2015


I've noticed another build issue on OS X that became apparent only after managing a full build and install.
The default now appears to be to create shared libraries with the install_name containing @rpath, with the alternative being a fully relative install_name (i.e. only the library name, no path at all). This is different from 5.4.2- where the default was to store the full path in the install_name (config += absolute_library_soname).

While the new rpath default is probably fine in Qt's preferred/standard way for creating stand-alone app-bundles that contain the required Qt frameworks, it breaks dynamic loading in all other cases, or at the very least when Qt is built to be installed in a central, shared location (as in MacPorts or Fink).

For now I'm handling this by setting +absolute_library_soname when configuring with -no-rpath (and that seems to have the intended result), but that is of course not quite correct semantically.
Supposing I were to submit a patch for this, how would I approach the issue? Allow something like "-rpath absolute" on OS X, maybe? Or have I been overlooking another way to add absolute_library_soname through configure?
Either way, I think this is a choice that should be available through configure, and documented by configure --help; I don't think it's acceptable to relegate this to a qmake -config call after running configure, like for LTO (ltcg) builds .


More information about the Development mailing list