Hello, 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 . R. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
