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

[René J.V. Bertin]

Hi,

I can't remember, did I file a bug report on this, or has the issue
already been picked up? I've seen others being bitten by it ...

R.

On 13 September 2015 at 04:20, Jake Petroules
<jake.petroules at petroules.com> wrote:
>
> 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:
>
> 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
>
...
>
> 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
>