1 |
Hi all, |
2 |
|
3 |
On Fri, Jan 30, 2015 at 09:04:40AM +0900, heroxbd@g.o wrote: |
4 |
|
5 |
> There are efforts on-going to make modern toolchain on gentoo-prefix @ |
6 |
> darwin. |
7 |
|
8 |
> I am sure guys from gentoo-alt (in the Cc) will show you the most recent |
9 |
> progress. |
10 |
|
11 |
I've been meaning to do a bit of a write-up on the state of things and |
12 |
the process I'm using currently. This seems like a good opportunity. |
13 |
|
14 |
Disclaimer: This is only my own personal understanding of things. I'm |
15 |
not a Gentoo or prefix developer. I might have misinterpreted something |
16 |
or all of it. I'm sure, the experts will correct me if I'm wrong |
17 |
somewhere. So read all of the following with healthy scepticism. ;) |
18 |
|
19 |
Compiling llvm/clang with prefix on OS X works almost out of the box |
20 |
now: You just bootstrap your prefix normally. That should since a few |
21 |
days ago yield a prefix with binutils-apple-6.1 and |
22 |
gcc-apple-4.2.1_p5666-r2. This prefix is able to |
23 |
|
24 |
# USE="clang" emerge =sys-devel/llvm-3.4.2 |
25 |
|
26 |
Note the version: llvm-3.5.0 and later require C++11 support to compile |
27 |
which gcc-apple doesn't have. But llvm-3.4.2 can be compiled using |
28 |
gcc-apple and can itself compile and link stuff with the new |
29 |
binutils-apple. |
30 |
|
31 |
Unfortunately that merge will almost certainly fail at the very last |
32 |
minute because of invalid install names in some iphone simulator runtime |
33 |
library. So either merge with FEATURE="allow_broken_install_names" or |
34 |
make an overlay with the llvm ebuilds in it and patch them with the |
35 |
patch from this bug: |
36 |
|
37 |
https://bugs.gentoo.org/show_bug.cgi?id=536716 |
38 |
|
39 |
This gives you an llvm/clang 3.4.2 that uses the the system's (see |
40 |
below) libstdc++ by default. You should be able to compile stuff with |
41 |
"-stdlib=libc++" using the system's libc++ headers and libraries thus |
42 |
gaining C++11 support. This is only necessary if you want to compile |
43 |
programs that require C++11 support such as llvm-3.5.1. |
44 |
|
45 |
There is another bug however that provides somewhat preliminary/hackish |
46 |
ebuilds for libc++abi and libc++ for Darwin: |
47 |
|
48 |
https://bugs.gentoo.org/show_bug.cgi?id=474748 |
49 |
https://bugs.gentoo.org/attachment.cgi?id=394024 |
50 |
|
51 |
With those in your overlay you can do an |
52 |
|
53 |
# emerge libcxx-apple |
54 |
|
55 |
and will get libc++-3.5.1 and its headers in your prefix. |
56 |
|
57 |
However you opt, you can now try a |
58 |
|
59 |
CC=clang CXX="clang++ -stdlib=libc++" USE="clang" emerge llvm |
60 |
|
61 |
(with those updated ebuilds from your overlay) and should get a fully |
62 |
working llvm/clang-3.5.1. I have installed an environment configuration |
63 |
in my $EPREFIX/etc/portage/env that automates that: |
64 |
|
65 |
michael@osx1010:~ # cat $EPREFIX/etc/portage/env/clanglibc++ |
66 |
CC=clang |
67 |
CXX="clang++ -stdlib=libc++" |
68 |
michael@osx1010:~ # cat $EPREFIX/etc/portage/package.env |
69 |
sys-devel/llvm clanglibc++ |
70 |
sys-devel/binutils-apple clanglibc++ |
71 |
|
72 |
A good final test is to recompile binutils-apple with libc++ and LTO |
73 |
support: |
74 |
|
75 |
USE="libcxx lto" emerge -1 binutils-apple |
76 |
|
77 |
Note how clang++ -stdlib=libc++ is now used to compile ld64 and how ld |
78 |
-v reports LTO support (unfortunately not when called via the |
79 |
binutils-config wrapper but when called directly): |
80 |
|
81 |
# $EPREFIX/usr/x86_64-apple-darwin14/binutils-bin/6.1/ld -v |
82 |
@(#)PROGRAM:ld PROJECT:ld64-241.9 (Gentoo binutils-apple-6.1) |
83 |
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m arm64 |
84 |
LTO support using: LLVM version 3.5.1 |
85 |
|
86 |
So now you should even be able to compile stuff using clang -flto. |
87 |
Beware: I've tried that and it works for an int main(void) {}. I have |
88 |
just tried it on binutils-apple and it produced an ld64 that can be run |
89 |
and outputs its version information. But compilation spewed "LTO |
90 |
remarks" like nothing I've ever seen: |
91 |
|
92 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer |
93 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified |
94 |
ld: LTO remark: <unknown>:0:0: vectorization is not beneficial and is not explicitly forced |
95 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer |
96 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified |
97 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer |
98 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified |
99 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: loop control flow is not understood by vectorizer |
100 |
ld: LTO remark: <unknown>:0:0: loop not vectorized: vectorization was not specified |
101 |
|
102 |
Finally it croaked on linking cctools stuff: |
103 |
|
104 |
undef: _prune_trie |
105 |
Undefined symbols for architecture x86_64: |
106 |
"_prune_trie", referenced from: |
107 |
_strip_symtab in strip.private.o |
108 |
ld: symbol(s) not found for architecture x86_64 |
109 |
|
110 |
Most likely the -flto was missing when compiling some file. So there's |
111 |
definitely some work to be done there. |
112 |
|
113 |
Finally there are some quirks you should be aware of when trying all of |
114 |
this: |
115 |
|
116 |
1. portage currently masks OS X 10.10 as 10.9 because |
117 |
gcc-apple-4.2.1_p5666-r2 can't currently cope with 10.10. This will |
118 |
influence clang as well. All the stuff you compile will default to |
119 |
deployment target 10.9 unless you explicitly override that using a |
120 |
command line option to clang. |
121 |
|
122 |
There is a patch in a bug that lifts that limitation: |
123 |
https://bugs.gentoo.org/show_bug.cgi?id=537826. With that in place in |
124 |
the gcc ebuild and recompiled gcc you can override |
125 |
|
126 |
export MACOSX_DEPLOYMENT_TARGET=10.9 |
127 |
|
128 |
from $PORTDIR/profiles/prefix/darwin/macos/10.10/profile.bashrc (the one |
129 |
marked with "this is not a typo") to 10.10 and get the expected |
130 |
behaviour on 10.10. |
131 |
|
132 |
2. As far as I was able to discern, clang/llvm are configured and |
133 |
patched to use -I$EPREFIX/usr/include and -L$EPREFIX/usr/lib by default. |
134 |
And it does work. But clang silently falls back to the system |
135 |
directories if for whatever reason it does not look there or is unhappy |
136 |
with what it finds or does not find there. So check your compiles from |
137 |
time to time to see if they're really using the headers and libraries |
138 |
you expect them to use. |
139 |
|
140 |
3. I've just recently noticed that clang++ *always* uses the system's |
141 |
libstdc++ because it just doesn't look for it anywhere else. I am looking |
142 |
into this and plan to write a patch for it. Obviously that's a |
143 |
no-brainer if you use libc++ anyway. |
144 |
|
145 |
4. If you would like to try cross-compiling to arm, then you're in |
146 |
totally uncharted territories. There is however a patch to the |
147 |
binutils-config ebuild that at least makes clang produce binaries at |
148 |
all: https://bugs.gentoo.org/show_bug.cgi?id=537684. |
149 |
|
150 |
5. llvm/clang silently uses the Xcode tools and SDKs to compile its |
151 |
runtime libraries. The patch from this bug forces it to use itself (the |
152 |
compiler it has just compiled and is about to install) to compile |
153 |
those runtimes: https://bugs.gentoo.org/show_bug.cgi?id=537342. This |
154 |
disables compliation of all the stuff for ios, however. |
155 |
|
156 |
> > other package that asks for a more recent gcc. Right now I get a |
157 |
> > working basic system but almost all "higher" application fail to build |
158 |
> > one or the other way. |
159 |
|
160 |
That's almost always due to the fact that Apple has started using clang |
161 |
extensions *in the system headers* and does not test it against other |
162 |
compilers any more. So while they have basic support for disabling those |
163 |
extensions e.g. in /usr/include/os/base.h they do not use them |
164 |
consistently. |
165 |
|
166 |
Those are __has_extension and __has_feature. There are two ways to deal |
167 |
with those: |
168 |
|
169 |
1. First check if the include of the offending heder is needed at all. I |
170 |
was able to make at least two packages work again by just removing a |
171 |
senseless include that was pulling in one of those __has_features. |
172 |
|
173 |
2. Define them to nothing as explained here: |
174 |
http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros |
175 |
|
176 |
Good luck! |
177 |
|
178 |
Michael |
179 |
|
180 |
> JC D <mail2jcdx@×××××.de> writes: |
181 |
|
182 |
> > here are the first results. It did not work so far because I found my |
183 |
> > gcc-4.7.3 on gentoo_prefix (Mac OS 10.10) is broken. emerge gcc works |
184 |
> > and installs but if I try to compile a simple hello.cpp I get a |
185 |
> > segmentation fault 11. I am using the new binutils-apple-6.1. So far |
186 |
> > it seems that I can not get a newer gcc and thus also no llvm or any |
187 |
> > other package that asks for a more recent gcc. Right now I get a |
188 |
> > working basic system but almost all "higher" application fail to build |
189 |
> > one or the other way. |
190 |
> > |
191 |
> > Now I try to get llvm/clang working. For the compilation I am going to |
192 |
> > use the native llvm-gcc and llvm-g++ from Mac. |
193 |
> > I set up a package.env for llvm with: |
194 |
> > sys-devel/llvm llvm.conf |
195 |
> > |
196 |
> > llvm.conf contains: |
197 |
> > CC=/usr/bin/llvm-gcc |
198 |
> > CXX=/usr/bin/llvm-g++ |
199 |
> > |
200 |
> > The compilation works but there is an error when writing the llvm |
201 |
> > files to the right path. Here are emerge --info |
202 |
> > show at bpaste |
203 |
> > |
204 |
> > |
205 |
> > |
206 |
> > |
207 |
> > image |
208 |
> > |
209 |
> > show at bpaste |
210 |
> > Portage 2.2.14-prefix (python |
211 |
> > 3.3.3-final-0, |
212 |
> > prefix/darwin/macos/10.10/x64, |
213 |
> > gcc-4.2.1, unavailable, 14.1.0 |
214 |
> > x86_64) |
215 |
> > ==================================. |
216 |
> > .. |
217 |
> > |
218 |
> > |
219 |
> > |
220 |
> > Auf bpaste.net anzeigen Vorschau nach Yahoo |
221 |
> > |
222 |
> > |
223 |
> > |
224 |
> > |
225 |
> > |
226 |
> > image |
227 |
> > and the log file https://bpaste.net/show/62a0d5b0d4f4 |
228 |
> > |
229 |
> > I will experiment further ... |
230 |
-- |
231 |
bye, |
232 |
Michael |