I'm (still) working on creating an RPATH macro.
There are still some issues opened, but maybe @drdanz can help me fix them.
-
Currently the first argument is only needed to create the option. I don't understand how I can use the CMakeDependentOption
and the CMakePackageConfigHelpers
to correctly parse the options.
-
Currently this macro enables by default RPATH. Honestly I don't see any disadvantage of enabling RPATH w.r.t. the old way (i.e. libraries and bins with completely wrong search paths). Different is the case if one wants to enable e full-name installation. Disabling the macro does not lead to full-name installation, but simply revert to cmake default (and incomplete) RPATH configuration. At least, this is what I understood so far.
-
This is an important point:
The variable CMAKE_INSTALL_RPATH_USE_LINK_PATH
simply automatically adds all the library search paths to the install rpath variable. This is handy but can lead to some problem.
I try to explain better:
Let's consider a gazebo-yarp plugin. It links to gazebo (default search path) and yarp (custom installation, but in my case it will reside at the same location of the plugin lib).
If I set the CMAKE_INSTALL_RPATH_USE_LINK_PATH
variable the resultant LC_RPATH will be
$ otool -l libgazebo_yarp_controlboard.dylib | grep LC_RPATH -A2
cmd LC_RPATH
cmdsize 32
path @loader_path/ (offset 12)
--
cmd LC_RPATH
cmdsize 48
path /usr/local/Cellar/gazebo4/4.0.0/lib (offset 12)
--
cmd LC_RPATH
cmdsize 72
path /usr/local/Cellar/gazebo4/4.0.0/lib/gazebo-4.0/plugins (offset 12)
--
cmd LC_RPATH
cmdsize 56
path /usr/local/Cellar/sdformat/2.0.1/lib (offset 12)
--
cmd LC_RPATH
cmdsize 56
path /usr/local/Cellar/protobuf/2.5.0/lib (offset 12)
--
cmd LC_RPATH
cmdsize 56
path /Users/makaveli/Projects/src/local/lib (offset 12)
otool -L libgazebo_yarp_controlboard.dylib
libgazebo_yarp_controlboard.dylib:
@rpath/libgazebo_yarp_controlboard.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libgazebo_yarp_singleton.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libYARP_OS.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_sig.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_math.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_dev.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_name.1.dylib (compatibility version 1.0.0, current version 2.3.63)
@rpath/libYARP_init.1.dylib (compatibility version 1.0.0, current version 2.3.63)
/usr/local/lib/libgazebo_transport.4.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/local/lib/libgazebo_physics.4.dylib (compatibility version 4.0.0, current version 4.0.0)
.....
The only useful line is the first one (@loader_path/
). All the others are useless because they refer to either full-name libraries (gazebo) or to yarp which is already "resolved" through @loader_path
.
If instead I disable the variable the result is the following:
$ otool -l libgazebo_yarp_controlboard.dylib | grep LC_RPATH -A2
cmd LC_RPATH
cmdsize 32
path @loader_path/ (offset 12)
Of course this is more clean, but it requires the cmake developer to know all the paths of the installed dependent (shared) variables.
- the bin or lib variable is not strictly correct: maybe I should change it to
target_dirs
and lib_dirs
.