Re: [CMake] still having rpath problems on osx

[Michael Jackson]

> On Dec 24, 2015, at 2:24 AM, Boudewijn Rempt  wrote:
> 
> On Wed, 23 Dec 2015, Michael Jackson wrote:
> 
>>> 
>>> Hm... Okay -- so, since I all my dependencies myself as cmake external 
>>> projects, I guess I want all of them set to rpath. I guess that for boost, 
>>> with its own build system, I'll need to add a separate fix-up step to my 
>>> cmake externals project for boost. I have to check how I can fix the 
>>> dependencies that are still automake/autoconf based. And I'll try what you 
>>> suggest below for my own project.
>> 
>> I have written scripts to do things like that for boost and ITK where the 
>> libraries do not have anything like @rpath or the absolute path to the 
>> installed library. After installing I run those scripts to “fix” the 
>> libraries so when I debug I can just run the application. During packaging I 
>> then run CMake’s BundleUtilities to copy in the libraries and adjust the 
>> libraries to have @rpath or @executable_path.
>> 
>> When fixing up a library make sure you also fix all the dependent libraries 
>> that might be there. For things like Boost or ITK their higher level 
>> libraries depend on their lower level libraries. Using “otool -L” you can 
>> see this. Make sure you update EVERY path in the library.
>> 
>> Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, 
>> HDF5.. ) so you will still need to run/write something that fixes all of 
>> those libraries. For our project we wrote a pure CMake script that does 
>> everything we need to fix up our bundles so that everything is self 
>> contained.
> 
> Hm... And it all did work when my project was still Qt4-based and I built on 
> Mavericks... And I've got about 300 libraries in the project, including 
> plugins. Resetting the id of broken libraries and then rebuilding my project 
> works. Are your scripts public so I can take a look and maybe reuse them?

https://github.com/dream3d/DREAM3D/blob/develop/Support/cmp/OSX_Tools/CompleteBundle.cmake.in
 


Note that the file is “configured” during our make process but you should be 
able to figure out what we are doing. We also ensure ALL of our 3rd Party 
Libraries (except Qt) are built with absolute paths as their “install_name” so 
that BundleUtilities can more easily find the libraries. With additional 
arguments BundleUtilities can find about any library you need.

Mike Jackson

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

-- 

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] still having rpath problems on osx

[Michael Jackson]

> On Dec 23, 2015, at 12:02 PM, Boudewijn Rempt  wrote:
> 
> On Tue, 22 Dec 2015, clin...@elemtech.com wrote:
> 
>> 
>> On Dec 21, 2015 12:26 PM, Boudewijn Rempt  wrote:
>>> 
>>> All libraries I link to are built. Some come with a cmake build system, 
>>> some with an automake build system, boost with something else altogether... 
>>> But I wouldn't have expected the way a library is built to make a 
>>> difference for the link lines in the library that links to the other 
>>> library. 
>> 
>> You may not expect this, but this is how it works.  @rpath is a way for a 
>> library to say, "i want to be found using rpaths"
>> 
> 
> Hm... Okay -- so, since I all my dependencies myself as cmake external 
> projects, I guess I want all of them set to rpath. I guess that for boost, 
> with its own build system, I'll need to add a separate fix-up step to my 
> cmake externals project for boost. I have to check how I can fix the 
> dependencies that are still automake/autoconf based. And I'll try what you 
> suggest below for my own project.

I have written scripts to do things like that for boost and ITK where the 
libraries do not have anything like @rpath or the absolute path to the 
installed library. After installing I run those scripts to “fix” the libraries 
so when I debug I can just run the application. During packaging I then run 
CMake’s BundleUtilities to copy in the libraries and adjust the libraries to 
have @rpath or @executable_path.

When fixing up a library make sure you also fix all the dependent libraries 
that might be there. For things like Boost or ITK their higher level libraries 
depend on their lower level libraries. Using “otool -L” you can see this. Make 
sure you update EVERY path in the library.

Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. 
) so you will still need to run/write something that fixes all of those 
libraries. For our project we wrote a pure CMake script that does everything we 
need to fix up our bundles so that everything is self contained.  

—
Mike Jackson

> 
>> I think you are trying to hard to fix the problem in your cmake, by setting 
>> too many variables.  The libraries you link against need fixed to behave how 
>> you want.
>> 
>> By setting
>> set(CMAKE_MACOSX_RPATH ON) you are setting @rpath for the install name of 
>> any library you build.
>> 
>> By setting INSTALL_RPATH, you are indicating directories to substitute 
>> @rpath at runtime.
>> 
>> 
>>> 
>>> * And for the library itself, I explicitly set: 
>>> if (APPLE)  set_target_properties(kritaimage PROPERTIES INSTALL_RPATH 
>>> "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks")
>>>  endif() 
>>> Though I sort of feel that it shouldn't be necessary to explicitly set an 
>>> rpath to something I build.
>> 
>> 
>> If you are going to install the library, you should set INSTALL_RPATH.
>> 
> 
> Well, the way I set it up, which may be wrong of course, I install all the 
> dependecies to ~/dev/i, then build the main application that uses those 
> dependencies. When developing, I run the app bundle directly, linked to the 
> dependencies in ~/dev/i/lib; when distributing, I use macdeployqt to populate 
> the app bundle with all the dependencies and data.
> 
> 
>> 
>> It is partly right.  However, you may find it simpler to change the id of 
>> libraries before you link against them.
>> For example
>> install_name_tool -id @rpath/libboost_system.dylib libboost_system.dylib
>> 
>> And use "install_name_tool -change" for any libraries that link against the 
>> library with the changed id, but only if you change the id after linking.
>> 
> 
> Thanks! I think I'm finally beginning to grasp the idea :-)
> 
> 
> -- 
> 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] still having rpath problems on osx

[Boudewijn Rempt]

On Tue, 22 Dec 2015, clin...@elemtech.com wrote:



On Dec 21, 2015 12:26 PM, Boudewijn Rempt  wrote:


All libraries I link to are built. Some come with a cmake build system, some with an automake build system, boost with something else altogether... But I wouldn't have expected the way a library is built to make a difference for the link lines in the library that links to the other library. 


You may not expect this, but this is how it works.  @rpath is a way for a library to say, 
"i want to be found using rpaths"



Hm... Okay -- so, since I all my dependencies myself as cmake external 
projects, I guess I want all of them set to rpath. I guess that for boost, with 
its own build system, I'll need to add a separate fix-up step to my cmake 
externals project for boost. I have to check how I can fix the dependencies 
that are still automake/autoconf based. And I'll try what you suggest below for 
my own project.


I think you are trying to hard to fix the problem in your cmake, by setting too 
many variables.  The libraries you link against need fixed to behave how you 
want.

By setting
set(CMAKE_MACOSX_RPATH ON) 
you are setting @rpath for the install name of any library you build.


By setting INSTALL_RPATH, you are indicating directories to substitute @rpath 
at runtime.




* And for the library itself, I explicitly set: 

if (APPLE) 
 set_target_properties(kritaimage PROPERTIES INSTALL_RPATH "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks") 
endif() 


Though I sort of feel that it shouldn't be necessary to explicitly set an rpath 
to something I build.



If you are going to install the library, you should set INSTALL_RPATH.



Well, the way I set it up, which may be wrong of course, I install all the 
dependecies to ~/dev/i, then build the main application that uses those 
dependencies. When developing, I run the app bundle directly, linked to the 
dependencies in ~/dev/i/lib; when distributing, I use macdeployqt to populate 
the app bundle with all the dependencies and data.




It is partly right.  However, you may find it simpler to change the id of 
libraries before you link against them.
For example
install_name_tool -id @rpath/libboost_system.dylib libboost_system.dylib

And use "install_name_tool -change" for any libraries that link against the 
library with the changed id, but only if you change the id after linking.



Thanks! I think I'm finally beginning to grasp the idea :-)


--
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] still having rpath problems on osx

[Boudewijn Rempt]

On Wed, 23 Dec 2015, Michael Jackson wrote:



Hm... Okay -- so, since I all my dependencies myself as cmake external 
projects, I guess I want all of them set to rpath. I guess that for boost, with 
its own build system, I'll need to add a separate fix-up step to my cmake 
externals project for boost. I have to check how I can fix the dependencies 
that are still automake/autoconf based. And I'll try what you suggest below for 
my own project.


I have written scripts to do things like that for boost and ITK where the 
libraries do not have anything like @rpath or the absolute path to the 
installed library. After installing I run those scripts to “fix” the libraries 
so when I debug I can just run the application. During packaging I then run 
CMake’s BundleUtilities to copy in the libraries and adjust the libraries to 
have @rpath or @executable_path.

When fixing up a library make sure you also fix all the dependent libraries 
that might be there. For things like Boost or ITK their higher level libraries 
depend on their lower level libraries. Using “otool -L” you can see this. Make 
sure you update EVERY path in the library.

Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. 
) so you will still need to run/write something that fixes all of those 
libraries. For our project we wrote a pure CMake script that does everything we 
need to fix up our bundles so that everything is self contained.


Hm... And it all did work when my project was still Qt4-based and I built on 
Mavericks... And I've got about 300 libraries in the project, including 
plugins. Resetting the id of broken libraries and then rebuilding my project 
works. Are your scripts public so I can take a look and maybe reuse them?

--
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] still having rpath problems on osx

[clinton]

On Dec 21, 2015 12:26 PM, Boudewijn Rempt  wrote:
>
> I'm still having rpath problems when creating libraries on OSX... And I'm not 
> sure what's going on here. Here's the output for a single library: 
>
> otool -L ../i/lib/libkritaimage.dylib 
> ../i/lib/libkritaimage.dylib: 
>  /Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  libboost_system.dylib (compatibility version 0.0.0, current version 
> 0.0.0) 
>  @rpath/libImath.12.dylib (compatibility version 12.0.0, current version 
> 12.0.0) 
>  @rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version 
> 22.0.0) 
>  @rpath/libIex.12.dylib (compatibility version 12.0.0, current version 
> 12.0.0) 
>  @rpath/libHalf.12.dylib (compatibility version 12.0.0, current version 
> 12.0.0) 
>  @rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current 
> version 12.0.0) 
>  /Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, 
> current version 8.4.0) 
>  @rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0) 
>  /Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility 
> version 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  @rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility 
> version 5.6.0, current version 5.6.0) 
>  /Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility 
> version 5.6.0, current version 5.6.0) 
>  @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 
> 5.6.0, current version 5.6.0) 
>  /Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, 
> current version 5.6.0) 
>  @rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, 
> current version 5.6.0) 
>  /Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version 
> 15.0.0, current version 15.0.0) 
>  /Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version 
> 5.0.0, current version 5.17.0) 
>  /Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, 
> current version 5.17.0) 
>  @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.1.0) 
>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 1225.1.1) 
>
> All libraries I link to are built. Some come with a cmake build system, some 
> with an automake build system, boost with something else altogether... But I 
> wouldn't have expected the way a library is built to make a difference for 
> the link lines in the library that links to the other library. 

You may not expect this, but this is how it works.  @rpath is a way for a 
library to say, "i want to be found using rpaths"

>
> Obviously, 
>   libboost_system.dylib (compatibility version 0.0.0, current version 
> 0.0.0) 
> is wrong -- it's got neither an @rpath, nor a full path. 

If it is wrong, you need to fix it in boost, or fix it with install_name_tool 
before linking against it.

>
> I'm not sure even why some libraries are linked to with @rpath and others 

[CMake] still having rpath problems on osx

[Boudewijn Rempt]

I'm still having rpath problems when creating libraries on OSX... And I'm not 
sure what's going on here. Here's the output for a single library:

otool -L ../i/lib/libkritaimage.dylib 
../i/lib/libkritaimage.dylib:

/Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libImath.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
@rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version 
22.0.0)
@rpath/libIex.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
@rpath/libHalf.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
@rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current version 
12.0.0)
/Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, 
current version 8.4.0)
@rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
/Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version 15.0.0, 
current version 15.0.0)
/Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
@rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility 
version 5.6.0, current version 5.6.0)
/Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
/Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
/Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
@rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility 
version 5.6.0, current version 5.6.0)
@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 
5.6.0, current version 5.6.0)
/Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, 
current version 5.6.0)
@rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, 
current version 5.6.0)
/Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version 
15.0.0, current version 15.0.0)
/Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version 
5.0.0, current version 5.17.0)
/Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, 
current version 5.17.0)
@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.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
1225.1.1)

All libraries I link to are built. Some come with a cmake build system, some 
with an automake build system, boost with something else altogether... But I 
wouldn't have expected the way a library is built to make a difference for the 
link lines in the library that links to the other library.

Obviously,
 libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
is wrong -- it's got neither an @rpath, nor a full path.

I'm not sure even why some libraries are linked to with @rpath and others with a 
full path after running a make install, but I cannot figure out why libboost_system

doesn't have anything.

libkritaimage is build with these settings:

* CMake is version 3.4.0

* Policy CMP0042 is set to NEW

* in the toplevel cmakelists.txt, there's

if (APPLE)
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)
endif ()

I'm feeling dense, but I just cannot make out the documentation for these 
variables...