Gentoo Archives: gentoo-alt

From: Michael Weiser <michael@×××××××××××××××.net>
To: gentoo-alt@l.g.o
Subject: [gentoo-alt] clang-5 on macOS
Date: Mon, 25 Dec 2017 23:30:45
1 Happy Christmas!
3 Is anyone (else) working to get clang-5 running in prefix on macOS?
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.
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.)
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.
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
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.
36 Does anyone remember why CMAKE_BUILD_WITH_INSTALL_RPATH was necessary
37 for cmake ebuilds?
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.
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.
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.
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.
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.
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 ( 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.
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.
82 Any comments on my approach would be highly appreciated. Patches
83 attached for documentation.
84 --
85 Thanks,
86 Michael


File name MIME type
cmake-utils-llvm.patch text/x-diff
clang-5.0.1-prefix-includes.patch text/x-diff
clang-5.0.1-darwin_prefix-include-paths.patch text/x-diff
compiler-rt-5.0.1-no-sdk.patch text/x-diff


Subject Author
Re: [gentoo-alt] clang-5 on macOS Fabian Groffen <grobian@g.o>