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

[Massimo Callegari]

Oh, and by "visible place" I mean this:
http://doc.qt.io/qt-5/osx-deployment.html

which is Qt5 docs and it still refers to Qt4 deployment with (now) wrong install_name_tool -change calls.



----- Messaggio originale -----
Da: Massimo Callegari <massimocallegari at yahoo.it>
A: "development at qt-project.org" <development at qt-project.org>
Cc: "jake.petroules at petroules.com" <jake.petroules at petroules.com>
Inviato: Lunedì 28 Settembre 2015 21:09
Oggetto: Qt 5.5.0 build issues on OS X : rpath

...if I may add my 2 cents on this...

It took me 3 days to figure out what the heck was going on with a Qt 5.5.1 snapshot.

Then I googled and found the heck.

If one doesn't find this specific line: 
http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.0#n578

Or this specific QTBUG: 
https://bugreports.qt.io/browse/QTBUG-31814

he's left on his own to figure things out.

The solution for me has been adding this to my project main .pro:

greaterThan(QT_MAJOR_VERSION, 4):greaterThan(QT_MINOR_VERSION, 4) {
    macx:QMAKE_LFLAGS += -Wl,-rpath, at executable_path/../Frameworks
}

But please guys, when introducing such an important change, you are warmthly invited to mention it in a visible place.

Not everybody use QtCreator or macdeployqt on OSX.

Up to Qt 5.4.2, I was used to have numerous .pri files to execute nametool calls and transform absolute paths to @executable relative paths.

With @rpath I admit it's easier now, but you have no idea how many bad words I said in those 3 days ! :)

Thanks,
Massimo




> On Sep 12, 2015, at 5:15 PM, René J.V. Bertin <rjvbertin at 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