[CMake] getting the rpath right on osx

[Clinton Stimpson]

On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote:
> Hi,
> 
> On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> > On Mon, 2 Nov 2015, Andreas Pakulat wrote:
> > 
> > I think the idea of using @rpath as install name of the Qt libraries is
> > 
> >> geared towards the usecase
> >> of shipping Qt within the application bundle of the application. In that
> >> case all you need is set
> >> the rpath @executable_path/../Frameworks or so in the executable and thus
> >> the app-bundle is
> >> relocatable. In order to get that with CMake you'll likely need to use
> >> the BundleUtilities, though
> >> its been so long since I used those I don't know if they can handle this
> >> scenario out of the box.
> > 
> > Yes, that's what I'm trying to do -- well, I'm trying to do two
> > things. One is setup a build environment where kde apps like desktoptojson
> > can run, the other is creating a bundle, preferably using the same
> > Qt. I got quite far by manually fixing up the applications built as part
> > of kcoreaddons
> 
> That would be fixed in kcoreaddons by extending the linker flags to include
> the mentioned -Wl,-rpath,<qtlibdir>. There's no provisioning for this
> inside CMake afaik since its hard for it to guess what the intention is.

CMake does automatically handle this.  If a library being linked has @rpath 
for its install ID, then CMake will insert the linker flag.  This takes care of 
the build time rpath.  And works for any library in target_link_libraries() 
where CMake knows its full path.  A -L/-l approach does not work, but that is 
usually done for system libraries, in which case we normally don't care about 
rpaths.

This kind of thing isn't handled automatically at install time, and requires 
the INSTALL_RPATH property to be set.

> My
> understanding (not a OSX expert yet here) is also that having the install
> name of a framework on OSX be something like @rpath is quite unusual. Thats
> usually something that users are 'patching' when they bundle their
> application via install_name_tool. And thats what CMake supports doing via
> the BundleUtilities module.

If install rpaths are set correctly, and all copied 3rd party libraries use 
@rpath, there is no need for patching with install_name_tool.


> 
> > and then manually patching up the executable inside the
> > bundle to have the @executable_path/../Frameworks rpath added. But I'm
> > still not sure why with a really simple example things don't work out
> > of the box: I guess I had better build Qt with -norpath.
> 
> See above, I think the way the Qt frameworks are setup when using -rpath is
> simply not expected/anticipated so far by CMake (or the people maintaining
> the qt5 cmake modules inside Qt).

It is handled fine by CMake.  If not, it would be a bug.

> 
> However I never tried to use BundleUtilities with such a framework, maybe
> they do manage to 'fixup' things for that as well. For a Qt4-based project
> I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle
> from BundleUtilities, so may be worth a try to avoid the manual steps.
> 
> Even a Qt built with -norpath would require doing some 'manual' things to
> get a all-in-one app bundle for the application (or use of
> BundleUtilities), to copy things around and adjust the install and link
> names in all the frameworks and executables to be related and thus make the
> application relocatable.

Yes, a Qt built with -norpath will require extra patching steps with 
install_name_tool.

Clint