[CMake] getting the rpath right on osx

Andreas Pakulat apaku at gmx.de
Mon Nov 2 11:30:49 EST 2015


Hi,

On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson <clinton at elemtech.com>
wrote:

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


Thanks for correcting me - didn't see your first mail until now either. It
seems I'm really out of touch with CMake these days :)

So I guess KDE frameworks that generate development-tools lack the
INSTALL_RPATH - at least that would explain the necessity to manually patch
them. A relative path like you mentioned should work as long as Qt is
installed in the same prefix as those tools - which is likely the common
case.

An end-user application then can either decide to be installed in the same
way or it wants an app-bundle, then it could use an INSTALL_RPATH like
@executable/../Frameworks and bunlde the Qt frameworks inside that
subdirectory.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151102/b95cce6b/attachment-0001.html>


More information about the CMake mailing list