1 |
Happy Christmas! |
2 |
|
3 |
Is anyone (else) working to get clang-5 running in prefix on macOS? |
4 |
|
5 |
After upgrading to macOS 10.13, a couple of packages stopped compiling |
6 |
with clang 3.9.1. The errors came from system headers. It looked like |
7 |
Apple had again used some funky new clang feature in them which 3.9.1 |
8 |
didn't support. |
9 |
|
10 |
(Disclamer: I left prefix untouched when updating. It's still running |
11 |
with CHOST=x86_64-apple-darwin16 and profile |
12 |
prefix/darwin/macos/10.12/x64.) |
13 |
|
14 |
Getting clang-5 up and running wasn't all that bad: I needed to clone |
15 |
the libcxx and libcxxabi ebuilds for version 5.0.1, adjust eclass |
16 |
cmake-utils and reintroduce some prefix provisions to clang and |
17 |
compiler-rt ebuilds that didn't make the move from the llvm ebuild. |
18 |
|
19 |
The cmake problem is somewhat tricky to explain: A special prefix |
20 |
handling is supposed to force all cmake-based builds to link against the |
21 |
libraries in prefix. This is done by setting an rpath and forcing cmake |
22 |
to use that rpath whenever possible. Normally, cmake will link the |
23 |
binaries for the build directory with an rpath that prefers libraries in |
24 |
the build directory. This is disabled by setting |
25 |
CMAKE_BUILD_WITH_INSTALL_RPATH. |
26 |
|
27 |
For LLVM and clang builds this causes a problem: Newly compiled binaries |
28 |
immediately get linked with the forced rpath. But the build calls some |
29 |
of them while still in the build directory and before installation of |
30 |
their libraries (especially llvm-tblgen and clang-tblgen). So they pick |
31 |
up the old installed versions of the libraries via the rpath and croak |
32 |
on missing symbols. I guess, other packages would face the same problem, |
33 |
if they called dynamically linked binaries from the build directory - |
34 |
which is somewhat rare. |
35 |
|
36 |
Does anyone remember why CMAKE_BUILD_WITH_INSTALL_RPATH was necessary |
37 |
for cmake ebuilds? |
38 |
|
39 |
Disabling this setting led to another problem: LLVM and clang have all |
40 |
their libs reference each other using @rpath. This is done relative to |
41 |
the executable they're linked into which gets an rpath of |
42 |
@executable_path/../lib for that purpose. This is fine as long as both |
43 |
LLVM and clang are built in one sitting. With the new concept of first |
44 |
building and installing LLVM and then building clang, the call to |
45 |
clang-tblgen in the build directory again croaks. But this time it is |
46 |
because dynamic LLVM libraries that get pulled in by the dynamic LLVM |
47 |
libraries it's linked against can't be found because they're not on its |
48 |
@rpath. So I had to force an *install* rpath of |
49 |
${EPREFIX}/usr/lib/llvm/${SLOT}/lib. |
50 |
|
51 |
With this I got llvm, clang and their other components installed. clang |
52 |
defaulted to /usr/include for includes at first and compiler-rt compiled |
53 |
against the Xcode SDK. With some research in the 3.9.1 ebuilds that was |
54 |
quickly remedied. |
55 |
|
56 |
The only real fallout came from the fact that my binutils-apple had LTO |
57 |
and tapi support enabled. Both broke horribly which rendered ld64 |
58 |
defunct. |
59 |
|
60 |
As long as neither USE tapi nor lto are enabled on binutils-apple, they |
61 |
should be fine. Symlinks to size and nm will break and will need |
62 |
adjustment to point to the new llvm install though. |
63 |
|
64 |
I think I got LTO support sorted in an updated binutils-apple-8.2.1 |
65 |
ebuild. I have also taken care of LLVMs move into a slotted |
66 |
$EPREFIX/usr/lib/llvm which should make them more robust to future |
67 |
updates and moves. |
68 |
|
69 |
But tapi is a real mess which shines a spotlight on a more fundamental |
70 |
problem: Apple has yet to release the source of Xcode 9. So tapi-1.30 |
71 |
won't compile with clang-5.0.1 any more. A tapi-2.0.0 open source drop |
72 |
on GitHub (https://github.com/ributzka/tapi) requires Apple-specific |
73 |
additions to LLVM (ObjCMetadata). Those from the last released Apple |
74 |
clang-8.0.0 are slightly incompatible to llvm-5.0.0 *and* this |
75 |
tapi-2.0.0. I am currently digging my way through that. |
76 |
|
77 |
In case anyone wonders: tapi is the library that supports SDK .tbd stub |
78 |
files. So if ld64 has no tapi support it can't use recent Apple SDKs, |
79 |
which for the purposes of a prefix install is no big deal, I guess. It |
80 |
might even serve as a flag that some package is trying to use an SDK. |
81 |
|
82 |
Any comments on my approach would be highly appreciated. Patches |
83 |
attached for documentation. |
84 |
-- |
85 |
Thanks, |
86 |
Michael |