OS X RPATH bug in OCL

This one is no fun ...

When linking OCL in OS X 10.8.5 w/ CMake 3.0.0 and XCode 5.1.1, errors like this occur

-- Installing: /opt/orocos/lib/orocos/macosx/ocl/liborocos-ocl-common-macosx.dylib
error: /usr/bin/install_name_tool: for: /opt/orocos/lib/orocos/macosx/ocl/liborocos-ocl-common-macosx.2.7.0.dylib (for architecture x86_64) option "-add_rpath /opt/orocos/lib/orocos/macosx/ocl" would duplicate path, file already has LC_RPATH for: /opt/orocos/lib/orocos/macosx/ocl
error: /usr/bin/install_name_tool: for: /opt/orocos/lib/orocos/macosx/ocl/liborocos-ocl-common-macosx.2.7.0.dylib (for architecture x86_64) option "-add_rpath /opt/orocos/lib" would duplicate path, file already has LC_RPATH for: /opt/orocos/lib
...
/usr/bin/install_name_tool: object: /opt/orocos/lib/orocos/macosx/ocl/liborocos-ocl-logging-macosx.2.7.0.dylib malformed object (load command 26 cmdsize is zero)
...
-- Installing: /opt/orocos/bin/deployer-macosx
/usr/bin/install_name_tool: object: /opt/orocos/bin/deployer-macosx malformed object (load command 34 cmdsize is zero)
/usr/bin/install_name_tool: object: /opt/orocos/bin/deployer-macosx malformed object (load command 34 cmdsize is zero)

And the deployer can not be executed. NB install_name_tool is used to manipulate the RPATH entries in a library or executable.


CMake 3.x has defaulted on certain RPATH handling, which may be why this isn't present in CMake 2.8.x by default. This is *not* due to the MacPorts install of the broken cctools port, but is instead caused by a bug in the system install_name_tool (thanks, Apple). In my case this is not due to inconsistent XCode + command line tools installs, though this can cause similar errors.

The root cause is that /usr/bin/install_name_tool corrupts a file if it removes a duplicate RPATH entry. Yeah, stoopid. CMake sets the RPATH in two places; once for the build tree, and a second time when installing. CMake already has some fixes to work around this.

http://www.cmake.org/Bug/view.php?id=14707

The actual CMake compiler command for the ocl-logging library has three RPATHs set, two of which are duplicate. That corrupts the dynamic library when linked. Removing the third entry (the duplicate of /opt/orocos/lib/orocos/macosx/ocl) fixes the build error (the first error above), but now when the RPATH entries are manipulated for installation you end up replacing the first entry (/opt/orocos/lib/orocos/macosx/ocl) with the install path (/opt/orocos/lib), which is now a duplicate of the second original entry, corrupting the library for a second time (the second type of error above). Ugh!

sudo /usr/bin/c++  -O2 -g -DNDEBUG -dynamiclib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/orocos/lib/orocos/macosx,-rpath,/opt/orocos/lib,-rpath,/opt/orocos/lib/orocos/macosx/ocl   -current_version 2.7.0 -o orocos/macosx/ocl/liborocos-ocl-logging-macosx.2.7.0.dylib -install_name /Users/sroderic/v2/orocos_ws/build_isolated/ocl/install/logging/orocos/macosx/ocl/liborocos-ocl-logging-macosx.2.7.0.dylib CMakeFiles/orocos-ocl-logging.dir/Appender.cpp.o CMakeFiles/orocos-ocl-logging.dir/FileAppender.cpp.o CMakeFiles/orocos-ocl-logging.dir/OstreamAppender.cpp.o CMakeFiles/orocos-ocl-logging.dir/RollingFileAppender.cpp.o CMakeFiles/orocos-ocl-logging.dir/LoggingService.cpp.o CMakeFiles/orocos-ocl-logging.dir/GenerationalFileAppender.cpp.o  -L/opt/orocos/lib /opt/orocos/lib/liborocos-rtt-macosx.2.7.0.dylib /opt/orocos/lib/liblog4cpp.dylib liborocos-ocl-log4cpp-macosx.2.7.0.dylib /opt/orocos/lib/liborocos-rtt-macosx.2.7.0.dylib /opt/local/lib/libboost_filesystem-mt.dylib /opt/local/lib/libboost_system-mt.dylib /opt/local/lib/libboost_serialization-mt.dylib /opt/local/lib/libxerces-c.dylib -ldl /opt/local/lib/libboost_thread-mt.dylib /opt/local/lib/libboost_date_time-mt.dylib /opt/orocos/lib/liblog4cpp.dylib

Does anyone remember why the RPATH is manually manipulated at all? Did CMake v2.8.x not deal as well with the RPATH?

I'm going to try to fix this by removing (some of?) the manual manipulation of the RPATH, and see whether it builds cleanly in OS X and Linux.

Hope this makes sense
S

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev