subject:"\[CMake\] getting the rpath right on osx"

Re: [CMake] getting the rpath right on osx

2015-11-02 Thread Andreas Pakulat

Hi,

On Mon, Nov 2, 2015 at 10:26 AM, Boudewijn Rempt  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, 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

Re: [CMake] getting the rpath right on osx

2015-11-02 Thread 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  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.

> 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

Re: [CMake] getting the rpath right on osx

2015-11-02 Thread clinton



- On Nov 2, 2015, at 2:26 AM, Boudewijn Rempt b...@valdyas.org 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

Re: [CMake] getting the rpath right on osx

2015-11-02 Thread 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

Re: [CMake] getting the rpath right on osx

2015-11-02 Thread Andreas Pakulat

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

Re: [CMake] getting the rpath right on osx

2015-11-02 Thread Andreas Pakulat

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

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

[CMake] getting the rpath right on osx

2015-11-02 Thread 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

Re: [CMake] getting the rpath right on osx

Re: [CMake] getting the rpath right on osx

Re: [CMake] getting the rpath right on osx

Re: [CMake] getting the rpath right on osx

Re: [CMake] getting the rpath right on osx

Re: [CMake] getting the rpath right on osx

[CMake] getting the rpath right on osx

7 matches

Site Navigation

Mail list logo

Footer information