[gentoo-alt] binutils-apple: LTO with current clang and update to XCode 7.0

[Michael Weiser <michael@weiser.dinsnail.net>]

Hi,

my Prefix has been in a sorry state lately. After some digging I found
the reason: My binutils-apple were compiled with USE="lto" and current
llvm/clang reference all their libraries via @rpath. This caused ld64 to
fail at startup because the libLTO.dylib it's linked against can't pull
in other libs like libLLVMCore:

michael@osx1011:/usr/local/gentoo/usr/lib $ ld
dyld: Library not loaded: @rpath/libLLVMCore.3.8.dylib
  Referenced from: /usr/local/gentoo/usr/lib/libLTO.3.8.0.dylib
  Reason: image not found
Trace/BPT trap: 5

What's even more confusing is that this message sometimes seems to come
from clang but is actually generated by ld:

michael@osx1011:~ $ clang -o t t.c
dyld: Library not loaded: @rpath/libLLVMCore.3.8.dylib
  Referenced from: /usr/local/gentoo/usr/bin/clang
  Reason: image not found
Trace/BPT trap: 5

So as a quick fix when running into this problem one can compile
binutils-apple-6.3 with USE="-lto" and
DYLD_LIBRARY_PATH=$EPREFIX/usr/lib set.

I went ahead and added some rpath LDFLAGS to my local overlay for
binutils-apple and now have a Prefix on OS X 10.11 with
binutils-apple-6.3[lto] and LLVM/Clang 3.8.0 that seems to work just
fine. Also, because of the use of @rpath all that error-prone fiddling
with install_name_tool in the llvm ebuild is now history. Awesome!

In the process I had a look at the binutils from Xcode 7.0: The source
of ld64-253.3 now massively uses C++11 language features. After some
hours of patching around I gave up on gcc support when I ran into
std::function and lambda functions.

Also, the as driver now actually calls "clang -integrated-as" *as the
assembler* for i686, x86_64 and arm targets. So Apple is now actively
eradicating the classic assembler. As far as I know, clang has been
using its own internal assembler for some time but now Apple also forces
it on everyone who calls as, like our good old gcc-4.2. For now this is
good for some quite verbose warnings about deprecated section names but
might have more effects later on. This also means that the classic
assembler won't get any fixes and updates for new versions of OS X any
more.

And finally, otool now uses (and has used for some time) LLVM
disassembling functions. For that it dynamically loads libLTO.dylib at
runtime. After some digging I found it so interwoven with the whole of
cctools that I gave up on supporting disabling LTO support as well.
Instead I now fix their rpath as well so that all LTO-based features
have a chance to work. Because loading is done at runtime, those
functions are just silently disabled if loading libLTO ever fails.

I now have a cleaned up ebuild for binutils-apple-7.0 that can only be
compiled using clang and always links ld64 against libLTO and sets the
correct rpath for runtime.

Would there be any interest in putting that in a bug for inclusion in
prefix?
-- 
bye, Micha
Elephants don't play chess!