getting the rpath right on osx

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

getting the rpath right on osx

Boudewijn Rempt
I checked the manual and the blog post about rpath on osx, but I'm still
confused, and still not getting it right...

I build and installed Qt 5.6 alpha like this:

./configure -prefix /Users/boudewijnrempt/kf5/i

Then I made a small test project, consisting of nothing but a main that links to QtCore.

If I build that with qmake, with this .pro file:

QT       += core
QT       -= gui
TARGET = rpathqmake
CONFIG   += console
CONFIG   -= app_bundle
TEMPLATE = app
SOURCES += main.cpp

The r-path is set:

Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
rpathqmake:
     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0)
     /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
     /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
rpathqmake:
     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0

If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and without all those RPATH related lines,
they don't seem to make a difference. I'm using cmake 3.3.2.

cmake_minimum_required(VERSION 2.8.12)
cmake_policy(SET CMP0042 NEW)
set(CMAKE_MACOSX_RPATH ON)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(REQUIRED_QT_VERSION 5.3.0)
find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
add_executable(rpathcmake main.cpp)
target_link_libraries(rpathcmake Qt5::Core)
install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)

Only adding something like this makes it work:

set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH "/Users/boudewijnrempt/kf5/i/lib")

Which I'm pretty sure is something I don't want.

Boudewijns-Mac-mini:test boudewijnrempt$ make install
[100%] Built target rpathcmake
Install the project...
-- Install configuration: ""
-- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
Boudewijns-Mac-mini:test boudewijnrempt$ otool -L /Users/boudewijnrempt/kf5/i/bin/rpathcmake
/Users/boudewijnrempt/kf5/i/bin/rpathcmake:
     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0)
     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake
dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
   Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
   Reason: image not found
Trace/BPT trap: 5
Boudewijns-Mac-mini:test boudewijnrempt$ otool -L /Users/boudewijnrempt/kf5/i/bin/rpathcmake
/Users/boudewijnrempt/kf5/i/bin/rpathcmake:
     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0)
     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)

What should I do?

--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
--

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
Reply | Threaded
Open this post in threaded view
|

Re: getting the rpath right on osx

Clinton Stimpson


----- On Nov 2, 2015, at 2:26 AM, Boudewijn Rempt [hidden email] wrote:

> I checked the manual and the blog post about rpath on osx, but I'm still
> confused, and still not getting it right...
>
> I build and installed Qt 5.6 alpha like this:
>
> ./configure -prefix /Users/boudewijnrempt/kf5/i
>
> Then I made a small test project, consisting of nothing but a main that links to
> QtCore.
>
> If I build that with qmake, with this .pro file:
>
> QT       += core
> QT       -= gui
> TARGET = rpathqmake
> CONFIG   += console
> CONFIG   -= app_bundle
> TEMPLATE = app
> SOURCES += main.cpp
>
> The r-path is set:
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
> rpathqmake:
>     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current
>     version 5.6.0)
>     /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
>     (compatibility version 1.0.0, current version 1.0.0)
>     /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
>     version 1.0.0, current version 275.0.0)
>     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
>     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>     1213.0.0)
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
> rpathqmake:
>     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current
>     version 5.6.0

Keep in mind, "otool -L" doesn't show rpaths.
@rpath/QtCore.framework/Versions/5/QtCore is not an rpath.
@rpath is a place holder where an rpath can be substituted.
Anytime you see "@rpath" what it means is that the dependent library wants to be found using rpaths.
Use "otool -l" | grep -A2 LC_RPATH to see the rpaths.

>
> If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and without
> all those RPATH related lines,
> they don't seem to make a difference. I'm using cmake 3.3.2.
>
> cmake_minimum_required(VERSION 2.8.12)
> cmake_policy(SET CMP0042 NEW)
> set(CMAKE_MACOSX_RPATH ON)
> SET(CMAKE_SKIP_BUILD_RPATH TRUE)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> set(REQUIRED_QT_VERSION 5.3.0)
> find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
> add_executable(rpathcmake main.cpp)
> target_link_libraries(rpathcmake Qt5::Core)
> install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)

If you remove
 set(CMAKE_MACOSX_RPATH ON)
 SET(CMAKE_SKIP_BUILD_RPATH TRUE)
 SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
 SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
then, it would probably be a minimal example.

>
> Only adding something like this makes it work:
>
> set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
> "/Users/boudewijnrempt/kf5/i/lib")
>
> Which I'm pretty sure is something I don't want.

To fix the errors below, you actually to do something like this.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
 "/Users/boudewijnrempt/kf5/i/lib")

What you probably want is to use a variable instead of an absolute path.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
 "@loader_path/../lib")

That property along with MACOSX_RPATH, or the global property CMAKE_MACOSX_RPATH are the 2 first variables you would set.
MACOSX_RPATH property on a target indicates that its install 'ID' contains @rpath, and it wants to be found using rpaths.  INSTALL_RPATH property is a list of rpaths to help find dependencies which want to be found using rpaths.

>
> Boudewijns-Mac-mini:test boudewijnrempt$ make install
> [100%] Built target rpathcmake
> Install the project...
> -- Install configuration: ""
> -- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
>     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current
>     version 5.6.0)
>     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
>     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>     1197.1.1)
> Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake
> dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
>   Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
>   Reason: image not found
> Trace/BPT trap: 5
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
>     @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current
>     version 5.6.0)
>     /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
>     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>     1197.1.1)
>
> What should I do?

Set the INSTALL_RPATH target property.

Clint

--

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
Reply | Threaded
Open this post in threaded view
|

Re: getting the rpath right on osx

Andreas Pakulat-2
In reply to this post by Boudewijn Rempt
Hi,

On Mon, Nov 2, 2015 at 10:26 AM, Boudewijn Rempt <[hidden email]> wrote:
I checked the manual and the blog post about rpath on osx, but I'm still
confused, and still not getting it right...

I build and installed Qt 5.6 alpha like this:

./configure -prefix /Users/boudewijnrempt/kf5/i

Then I made a small test project, consisting of nothing but a main that links to QtCore.

If I build that with qmake, with this .pro file:

QT       += core
QT       -= gui
TARGET = rpathqmake
CONFIG   += console
CONFIG   -= app_bundle
TEMPLATE = app
SOURCES += main.cpp

The r-path is set:

Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
rpathqmake:
    @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0)
    /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
rpathqmake:
    @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0

Thats not the rpath in your executable, thats just the install name of the QtCore library. And the install name indicates that you need to set an rpath in your executable that points to the installation directory of Qt. In order to see the rpath entries of your executable you'll need to check for the LC_RPATH command in the output of this:

otool -l rpathqmake

It will show the absolute path to the Qt installation on your system.
 
If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and without all those RPATH related lines,
they don't seem to make a difference. I'm using cmake 3.3.2.

cmake_minimum_required(VERSION 2.8.12)
cmake_policy(SET CMP0042 NEW)
set(CMAKE_MACOSX_RPATH ON)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(REQUIRED_QT_VERSION 5.3.0)
find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
add_executable(rpathcmake main.cpp)
target_link_libraries(rpathcmake Qt5::Core)
install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)

Only adding something like this makes it work:

set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH "/Users/boudewijnrempt/kf5/i/lib")

I guess thats where your Qt is installed to? Then yes, that is exactly what you want since thats where Qt is and the Qt libraries require an rpath to be set to be found since 5.5 on OSX. You just don't want to hardcode this, but rather calculate it off of the path of the QtCore library. Or even better would be if the Qt5 cmake modules would provide some provision to add the necessary linker commandline argument to inject the rpath during linking into the executable. Thats how qmake makes things 'work out of the box', it knows Qt has been built with the rpath-flag (default since 5.5) and then adds something like -Wl,-rpath,<qtlibdir> to the linker commandline of the generated Makefile.

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.

Andreas

--

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
Reply | Threaded
Open this post in threaded view
|

Re: getting the rpath right on osx

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

Boudewijn
--

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
Reply | Threaded
Open this post in threaded view
|

Re: getting the rpath right on osx

Andreas Pakulat-2
Hi,

On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <[hidden email]> 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. 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.
 
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).

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.

Andreas

--

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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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

--

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
Reply | Threaded
Open this post in threaded view
|

Re: getting the rpath right on osx

Andreas Pakulat-2
Hi,

On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson <[hidden email]> 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 <[hidden email]> 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

--

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