> On Sep 12, 2015, at 3:43 AM, René J.V. Bertin <[email protected]> wrote: > > 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)
Relative install names are useless, there is virtually no reason you'd want this. > 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). Dynamic library loading on Apple platforms is done in a decoupled manner - on OS X 10.5 and above you should always prefix the install name of a library with @rpath, and it is the loading binary's responsibility to specify (using an rpath list) where it will look for its dependent libraries (rather than the dependent library specifying where its depending binaries will look for it, which is clearly backwards). So, this doesn't break dynamic loading, per se. You would just need to specify the (absolute) install location of Qt as an rpath in your binary, and everything works fine. However, in cases where Qt is intended to not be relocated (your MacPorts/Fink case), it can be more convenient to use an absolute install name, and then your loading binary need not specify that path in its rpath list. Note that the install name of a library gets embedded in your binary when you link to it - that's why no rpath list is needed to load a library that you've linked to, which has an absolute install name. When it has an rpath, that @rpath is a placeholder which is to be replaced with each entry in the calling binary's rpath list until a match is found, and then the library is loaded. Many people seem to be confused by this decoupled aspect of loading and how it's intended to be used (further, many people don't realize rpath is a LIST, not a single entry), so I want to make sure you understand it properly. > 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. If you're configuring with -no-rpath, the only valid thing in combination with this case is an absolute install name, so you should not need to specify it additionally. > 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 "-rpath absolute" is conceptually invalid. What you want is -no-rpath, which uses absolute sonames and doesn't embed any rpaths in any binaries. If that alone is insufficient, there is a bug. I'd expect a Qt framework from a -no-rpath build and other default configure options to have an install name of i.e. /usr/local/Qt-5.6.0/lib/QtCore.framework/Versions/5/QtCore, and no rpath list. Which of these things don't happen when using -no-rpath? -- Jake Petroules - jake.petroules at petroules.com
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
