> On Sep 12, 2015, at 5:15 PM, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Saturday September 12 2015 14:22:28 Jake Petroules wrote: > >> >> Relative install names are useless, there is virtually no reason you'd want >> this. > > Not without something like @framework or @loader_path in from of them, no. > >> 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. > > I'm not used to using @rpath myself, but I guess it doesn't help that Apple > don't seem to be using them often outside of items in app bundles. > >> 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 > > The alternative would be to patch all dependent code so that it specifies the > correct @rpath list, which isn't really an option, really ... > >>> 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? >> "-rpath absolute" is conceptually invalid. > > Isn't an rpath on Linux simply the full path to the shared library? That's > what I had in mind in any case.
rpath is a *list* where the binary searches for its dependents. On Linux it normally contains a single entry: $ORIGIN/../lib and on OS X / iOS normally contains a single entry like @loader_path/../Frameworks but frameworks might have two, like @loader_path/Frameworks and @loader_path/../Frameworks >> 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. > >> 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? > > > - with Qt 5.4.2, the default (-rpath) build added absolute_library_soname to > QT_CONFIG, leading to install names like > /opt/local/libexec/qt5/Library/QtCore.framework/Versions/5/QtCore Yep, because -rpath never worked at all on Apple platforms prior to 5.5. > - with Qt 5.5.0, using -no-rpath leads to install names without a path, like > QtCore . > - Adding absolute_library_soname to QT_CONFIG on OS X when -no-rpath is given > restores the expected behaviour. > > So yes, someone removed the absolute_library_soname from the -rpath case, but > forgot to move it (or didn't realise it have to be moved) to the -no-rpath > case. Sounds like it. absolute_library_soname should default to true with -no-rpath, and false with -rpath. > > R. -- Jake Petroules - jake.petroules at petroules.com
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development