| 1 |
Hi, |
| 2 |
|
| 3 |
my Prefix has been in a sorry state lately. After some digging I found |
| 4 |
the reason: My binutils-apple were compiled with USE="lto" and current |
| 5 |
llvm/clang reference all their libraries via @rpath. This caused ld64 to |
| 6 |
fail at startup because the libLTO.dylib it's linked against can't pull |
| 7 |
in other libs like libLLVMCore: |
| 8 |
|
| 9 |
michael@osx1011:/usr/local/gentoo/usr/lib $ ld |
| 10 |
dyld: Library not loaded: @rpath/libLLVMCore.3.8.dylib |
| 11 |
Referenced from: /usr/local/gentoo/usr/lib/libLTO.3.8.0.dylib |
| 12 |
Reason: image not found |
| 13 |
Trace/BPT trap: 5 |
| 14 |
|
| 15 |
What's even more confusing is that this message sometimes seems to come |
| 16 |
from clang but is actually generated by ld: |
| 17 |
|
| 18 |
michael@osx1011:~ $ clang -o t t.c |
| 19 |
dyld: Library not loaded: @rpath/libLLVMCore.3.8.dylib |
| 20 |
Referenced from: /usr/local/gentoo/usr/bin/clang |
| 21 |
Reason: image not found |
| 22 |
Trace/BPT trap: 5 |
| 23 |
|
| 24 |
So as a quick fix when running into this problem one can compile |
| 25 |
binutils-apple-6.3 with USE="-lto" and |
| 26 |
DYLD_LIBRARY_PATH=$EPREFIX/usr/lib set. |
| 27 |
|
| 28 |
I went ahead and added some rpath LDFLAGS to my local overlay for |
| 29 |
binutils-apple and now have a Prefix on OS X 10.11 with |
| 30 |
binutils-apple-6.3[lto] and LLVM/Clang 3.8.0 that seems to work just |
| 31 |
fine. Also, because of the use of @rpath all that error-prone fiddling |
| 32 |
with install_name_tool in the llvm ebuild is now history. Awesome! |
| 33 |
|
| 34 |
In the process I had a look at the binutils from Xcode 7.0: The source |
| 35 |
of ld64-253.3 now massively uses C++11 language features. After some |
| 36 |
hours of patching around I gave up on gcc support when I ran into |
| 37 |
std::function and lambda functions. |
| 38 |
|
| 39 |
Also, the as driver now actually calls "clang -integrated-as" *as the |
| 40 |
assembler* for i686, x86_64 and arm targets. So Apple is now actively |
| 41 |
eradicating the classic assembler. As far as I know, clang has been |
| 42 |
using its own internal assembler for some time but now Apple also forces |
| 43 |
it on everyone who calls as, like our good old gcc-4.2. For now this is |
| 44 |
good for some quite verbose warnings about deprecated section names but |
| 45 |
might have more effects later on. This also means that the classic |
| 46 |
assembler won't get any fixes and updates for new versions of OS X any |
| 47 |
more. |
| 48 |
|
| 49 |
And finally, otool now uses (and has used for some time) LLVM |
| 50 |
disassembling functions. For that it dynamically loads libLTO.dylib at |
| 51 |
runtime. After some digging I found it so interwoven with the whole of |
| 52 |
cctools that I gave up on supporting disabling LTO support as well. |
| 53 |
Instead I now fix their rpath as well so that all LTO-based features |
| 54 |
have a chance to work. Because loading is done at runtime, those |
| 55 |
functions are just silently disabled if loading libLTO ever fails. |
| 56 |
|
| 57 |
I now have a cleaned up ebuild for binutils-apple-7.0 that can only be |
| 58 |
compiled using clang and always links ld64 against libLTO and sets the |
| 59 |
correct rpath for runtime. |
| 60 |
|
| 61 |
Would there be any interest in putting that in a bug for inclusion in |
| 62 |
prefix? |
| 63 |
-- |
| 64 |
bye, Micha |
| 65 |
Elephants don't play chess! |
Archives