[gentoo-alt] clang-5 on macOS

[Michael Weiser]

Happy Christmas!

Is anyone (else) working to get clang-5 running in prefix on macOS?

After upgrading to macOS 10.13, a couple of packages stopped compiling
with clang 3.9.1. The errors came from system headers. It looked like
Apple had again used some funky new clang feature in them which 3.9.1
didn't support.

(Disclamer: I left prefix untouched when updating. It's still running
with CHOST=x86_64-apple-darwin16 and profile
prefix/darwin/macos/10.12/x64.)

Getting clang-5 up and running wasn't all that bad: I needed to clone
the libcxx and libcxxabi ebuilds for version 5.0.1, adjust eclass
cmake-utils and reintroduce some prefix provisions to clang and
compiler-rt ebuilds that didn't make the move from the llvm ebuild.

The cmake problem is somewhat tricky to explain: A special prefix
handling is supposed to force all cmake-based builds to link against the
libraries in prefix. This is done by setting an rpath and forcing cmake
to use that rpath whenever possible. Normally, cmake will link the
binaries for the build directory with an rpath that prefers libraries in
the build directory. This is disabled by setting
CMAKE_BUILD_WITH_INSTALL_RPATH.

For LLVM and clang builds this causes a problem: Newly compiled binaries
immediately get linked with the forced rpath. But the build calls some
of them while still in the build directory and before installation of
their libraries (especially llvm-tblgen and clang-tblgen). So they pick
up the old installed versions of the libraries via the rpath and croak
on missing symbols. I guess, other packages would face the same problem,
if they called dynamically linked binaries from the build directory -
which is somewhat rare.

Does anyone remember why CMAKE_BUILD_WITH_INSTALL_RPATH was necessary
for cmake ebuilds?

Disabling this setting led to another problem: LLVM and clang have all
their libs reference each other using @rpath. This is done relative to
the executable they're linked into which gets an rpath of
@executable_path/../lib for that purpose. This is fine as long as both
LLVM and clang are built in one sitting. With the new concept of first
building and installing LLVM and then building clang, the call to
clang-tblgen in the build directory again croaks. But this time it is
because dynamic LLVM libraries that get pulled in by the dynamic LLVM
libraries it's linked against can't be found because they're not on its
@rpath. So I had to force an *install* rpath of
${EPREFIX}/usr/lib/llvm/${SLOT}/lib.

With this I got llvm, clang and their other components installed. clang
defaulted to /usr/include for includes at first and compiler-rt compiled
against the Xcode SDK. With some research in the 3.9.1 ebuilds that was
quickly remedied.

The only real fallout came from the fact that my binutils-apple had LTO
and tapi support enabled. Both broke horribly which rendered ld64
defunct.

As long as neither USE tapi nor lto are enabled on binutils-apple, they
should be fine. Symlinks to size and nm will break and will need
adjustment to point to the new llvm install though.

I think I got LTO support sorted in an updated binutils-apple-8.2.1
ebuild. I have also taken care of LLVMs move into a slotted
$EPREFIX/usr/lib/llvm which should make them more robust to future
updates and moves.

But tapi is a real mess which shines a spotlight on a more fundamental
problem: Apple has yet to release the source of Xcode 9. So tapi-1.30
won't compile with clang-5.0.1 any more. A tapi-2.0.0 open source drop
on GitHub (https://github.com/ributzka/tapi) requires Apple-specific
additions to LLVM (ObjCMetadata). Those from the last released Apple
clang-8.0.0 are slightly incompatible to llvm-5.0.0 *and* this
tapi-2.0.0. I am currently digging my way through that.

In case anyone wonders: tapi is the library that supports SDK .tbd stub
files. So if ld64 has no tapi support it can't use recent Apple SDKs,
which for the purposes of a prefix install is no big deal, I guess. It
might even serve as a flag that some package is trying to use an SDK.

Any comments on my approach would be highly appreciated. Patches
attached for documentation.
-- 
Thanks,
Michael