Me again, On Tue, Dec 26, 2017 at 09:35:40PM +0100, Michael Weiser wrote:
> We do want a > minimal CMAKE_INSTALL_RPATH (with just the path this project's libraries > get installed to) and CMAKE_INSTALL_RPATH_USE_LINK_PATH because of > https://cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH. This way > cmake will automatically add the directories of libraries that a project > links against and that are outside the build directory. No idea how the > first part can be done without help by the upstream source or the > individual ebuilds though. >From the binutils-config ldwrapper.c: * On ELF platforms, the wrapper will then add -R (-rpath) entries for * all -L entries found in the invocation to ensure the libraries found * at link time will be found at runtime too. That's basically what cmake does. We could do the same on Darwin. I think the only reason it wasn't needed until now was that every single dylib on Darwin normally brings its own path with it upon linking. This would invalidate the need to fiddle with cmake-utils.eclass. It might cause some other undesired behaviour though, like build directory paths leaking into rpaths... I will try the MACOSX_RPATH ON setting for llvm and clang. According to above link this should disable the @rpath install names and get us back the standard absolute paths in dylibs. -- Bye, Michael
