From cmake Mon Nov 02 16:30:49 2015 From: Andreas Pakulat Date: Mon, 02 Nov 2015 16:30:49 +0000 To: cmake Subject: Re: [CMake] getting the rpath right on osx Message-Id: X-MARC-Message: https://marc.info/?l=cmake&m=144648216816816 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1585237343==" --===============1585237343== Content-Type: multipart/alternative; boundary=001a11c1205eceb1670523914c85 --001a11c1205eceb1670523914c85 Content-Type: text/plain; charset=UTF-8 Hi, On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson 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 > 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,. 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 --001a11c1205eceb1670523914c85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson <<= a href=3D"mailto:clinton@elemtech.com" target=3D"_blank">clinton@elemtech.c= om> wrote:
On Monday, No= vember 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 librar= ies is
> >
> >> geared towards the usecase
> >> of shipping Qt within the application bundle of the applicati= on. In that
> >> case all you need is set
> >> the rpath @executable_path/../Frameworks or so in the executa= ble and thus
> >> the app-bundle is
> >> relocatable. In order to get that with CMake you'll likel= y 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 desk= toptojson
> > can run, the other is creating a bundle, preferably using the sam= e
> > 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 in= clude
> the mentioned -Wl,-rpath,<qtlibdir>. There's no provisioning= for this
> inside CMake afaik since its hard for it to guess what the intention i= s.

CMake does automatically handle this.=C2=A0 If a library being linke= d has @rpath
for its install ID, then CMake will insert the linker flag.=C2=A0 This take= s care of
the build time rpath.=C2=A0 And works for any library in target_link_librar= ies()
where CMake knows its full path.=C2=A0 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 req= uires
the INSTALL_RPATH property to be set.

Thank= s for correcting me - didn't see your first mail until now either. It s= eems 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 inst= alled in the same prefix as those tools - which is likely the common case.<= /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 a= n INSTALL_RPATH like @executable/../Frameworks and bunlde the Qt frameworks= inside that subdirectory.

Andreas
--001a11c1205eceb1670523914c85-- --===============1585237343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- 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 --===============1585237343==--