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