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! |