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

[René J.V. Bertin]

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.

> 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
- 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.

R.