[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] getting the rpath right on osx
From: Andreas Pakulat <apaku () gmx ! de>
Date: 2015-11-02 16:30:49
Message-ID: CAExHGmT8iqf9MKgCkqvVYVTNAT0uDN8nzBSXJkX3A7k79qBx5A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson <clinton@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@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
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov \
2, 2015 at 4:26 PM, Clinton Stimpson <span dir="ltr"><<a \
href="mailto:clinton@elemtech.com" \
target="_blank">clinton@elemtech.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span \
class="">On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote:<br> > \
Hi,<br> ><br>
> On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <<a \
href="mailto:boud@valdyas.org">boud@valdyas.org</a>> wrote:<br> > > On Mon, \
2 Nov 2015, Andreas Pakulat wrote:<br> > ><br>
> > I think the idea of using @rpath as install name of the Qt libraries is<br>
> ><br>
> >> geared towards the usecase<br>
> >> of shipping Qt within the application bundle of the application. In \
that<br> > >> case all you need is set<br>
> >> the rpath @executable_path/../Frameworks or so in the executable and \
thus<br> > >> the app-bundle is<br>
> >> relocatable. In order to get that with CMake you'll likely need to \
use<br> > >> the BundleUtilities, though<br>
> >> its been so long since I used those I don't know if they can handle \
this<br> > >> scenario out of the box.<br>
> ><br>
> > Yes, that's what I'm trying to do -- well, I'm trying to do \
two<br> > > things. One is setup a build environment where kde apps like \
desktoptojson<br> > > can run, the other is creating a bundle, preferably using \
the same<br> > > Qt. I got quite far by manually fixing up the applications \
built as part<br> > > of kcoreaddons<br>
><br>
> That would be fixed in kcoreaddons by extending the linker flags to include<br>
> the mentioned -Wl,-rpath,<qtlibdir>. There's no provisioning for \
this<br> > inside CMake afaik since its hard for it to guess what the intention \
is.<br> <br>
</span>CMake does automatically handle this. If a library being linked has \
@rpath<br> for its install ID, then CMake will insert the linker flag. This takes \
care of<br> the build time rpath. And works for any library in \
target_link_libraries()<br> where CMake knows its full path. A -L/-l approach does \
not work, but that is<br> usually done for system libraries, in which case we \
normally don't care about<br> rpaths.<br>
<br>
This kind of thing isn't handled automatically at install time, and requires<br>
the INSTALL_RPATH property to be set.</blockquote><div><br></div><div>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 :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Andreas</div></div></div></div>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at: \
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more information \
on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at \
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic