1 |
Hi Fabian, |
2 |
|
3 |
On Sat, Jan 31, 2015 at 04:57:55PM +0100, Fabian Groffen wrote: |
4 |
|
5 |
> > There is another bug however that provides somewhat preliminary/hackish |
6 |
> > ebuilds for libc++abi and libc++ for Darwin: |
7 |
> > |
8 |
> > https://bugs.gentoo.org/show_bug.cgi?id=474748 |
9 |
> > https://bugs.gentoo.org/attachment.cgi?id=394024 |
10 |
> I'll try and see if I can add these. I'd love to get into a state where |
11 |
> we can bootstrap into a fully self-providing clang. |
12 |
|
13 |
I've just updated those with my most recent ones. They aren't all that |
14 |
hackish anymore and tested quite a bit. As always, backporting to older |
15 |
OS Xes revealed some misconceptions and dependencies. But since they |
16 |
started life somewhere completely different and were hacked by different |
17 |
people and finally put on a strict diet by me (dropped multilib stuff |
18 |
and made them plain, straightforward ebuilds), they might not confirm to |
19 |
some Gentoo policies. So please feel free to subject them to some |
20 |
scrutiny. |
21 |
|
22 |
> > Note how clang++ -stdlib=libc++ is now used to compile ld64 and how ld |
23 |
> > -v reports LTO support (unfortunately not when called via the |
24 |
> > binutils-config wrapper but when called directly): |
25 |
> I'll try to tackle this, I guess it's because we insist on adding |
26 |
> command line arguments even through you do nothing. |
27 |
|
28 |
Come to think of it, I'm pretty sure, it's at least partly Apple |
29 |
braindeadness at work. The code for option -v in ld64 actually reads: |
30 |
|
31 |
fprintf(stderr, "configured to support archs: %s\n", ALL_SUPPORTED_ARCHS); |
32 |
// if only -v specified, exit cleanly |
33 |
if ( argc == 2 ) { |
34 |
const char* ltoVers = lto::version(); |
35 |
if ( ltoVers != NULL ) |
36 |
fprintf(stderr, "LTO support using: %s\n", ltoVers); |
37 |
exit(0); |
38 |
} |
39 |
|
40 |
I guess, once upon a time, they wanted to exit immediately if called |
41 |
with only -v and then someone stuck the LTO support message into the |
42 |
wrong code block. So now they only inform about LTO support if *only* -v |
43 |
was given and they're gonna exit. Worse: Some braindead script somewhere |
44 |
*will* expect it to behave that way. So basically the only thing to be |
45 |
done is to make the wrapper not add any additional options if it itself |
46 |
was called with only -v. |
47 |
|
48 |
> > Finally it croaked on linking cctools stuff: |
49 |
> > |
50 |
> > undef: _prune_trie |
51 |
> > Undefined symbols for architecture x86_64: |
52 |
> > "_prune_trie", referenced from: |
53 |
> > _strip_symtab in strip.private.o |
54 |
> > ld: symbol(s) not found for architecture x86_64 |
55 |
> > |
56 |
> > Most likely the -flto was missing when compiling some file. So there's |
57 |
> > definitely some work to be done there. |
58 |
> Ok. Recently I saw a problem like this with Apple's Clang which was |
59 |
> caused by the respective functions declared inline (e.g. bug). But I |
60 |
> guess this is a different issue. |
61 |
|
62 |
Mhmm, it's always the same: Up until this writeup, LTO wasn't really on |
63 |
my project list. Now I've got to know. I'll give it some digging. :) |
64 |
|
65 |
> > 1. portage currently masks OS X 10.10 as 10.9 because |
66 |
> > gcc-apple-4.2.1_p5666-r2 can't currently cope with 10.10. This will |
67 |
> > influence clang as well. All the stuff you compile will default to |
68 |
> > deployment target 10.9 unless you explicitly override that using a |
69 |
> > command line option to clang. |
70 |
> > |
71 |
> > There is a patch in a bug that lifts that limitation: |
72 |
> > https://bugs.gentoo.org/show_bug.cgi?id=537826. With that in place in |
73 |
> > the gcc ebuild and recompiled gcc you can override |
74 |
> I'll apply this and lift the awkward limitation. |
75 |
|
76 |
This might need to be done in quite some steps: Can you have a |
77 |
dependency in a profile on a certain package version being installed |
78 |
*before* the new profile is used? Otherwise we'd have to wait until |
79 |
everyone has updated their gcc-apple before setting |
80 |
MACOSX_DEPLOYMENT_TARGET to 10.10. |
81 |
|
82 |
Also: I found that ld64 from binutils-apple-4.3 doesn't understand 10.10 |
83 |
as a deployment target either. I've backported the fix from 6.1 and have |
84 |
an updated ebuild. A new bug for that should pop up in a couple of |
85 |
hours, I think. But that would still become 4.3-r1, I guess, so that we'd |
86 |
need to require people to update their binutils-apple as well before |
87 |
changing the deployment target in the profile. |
88 |
|
89 |
On a positive note: I've had the ld wrapper that doesn't add |
90 |
-macos-version-min to the linker command line in use for some time and |
91 |
haven't had any fallout yet with or without deployment target being set |
92 |
to 10.10. |
93 |
|
94 |
> > 2. As far as I was able to discern, clang/llvm are configured and |
95 |
> > patched to use -I$EPREFIX/usr/include and -L$EPREFIX/usr/lib by default. |
96 |
> > And it does work. But clang silently falls back to the system |
97 |
> > directories if for whatever reason it does not look there or is unhappy |
98 |
> > with what it finds or does not find there. So check your compiles from |
99 |
> > time to time to see if they're really using the headers and libraries |
100 |
> > you expect them to use. |
101 |
> Hmmm, this is bad :( |
102 |
|
103 |
Nah, not all that bad: The last time that happened for me was when I |
104 |
worked on bootstrapping libc++ and actually was missing the headers from |
105 |
my prefix. All I wanted to point out was that clang in prefix isn't as |
106 |
well tested as gcc and binutils where we've even got special wrappers in |
107 |
place to bend them to our will. So people should be aware to look out |
108 |
for this kind of thing wheras with gcc they might just expect that to |
109 |
work. |
110 |
|
111 |
> > 3. I've just recently noticed that clang++ *always* uses the system's |
112 |
> > libstdc++ because it just doesn't look for it anywhere else. I am looking |
113 |
> > into this and plan to write a patch for it. Obviously that's a |
114 |
> > no-brainer if you use libc++ anyway. |
115 |
> This is even worse :( |
116 |
|
117 |
Yep, this is bad. What's worse: Clang has a GCCInstallationDetector. And |
118 |
that has a path for Gentoo in |
119 |
clang-3.5-gentoo-runtime-gcc-detection-v3.patch. But that's only used on |
120 |
Linux. :-( |
121 |
|
122 |
The equivalent Darwin function is really tiny and just concerned with |
123 |
what library name to use but not which path to look in. They try |
124 |
/usr/lib and otherwise just put -lstdc++ to the linker and let it |
125 |
search. But even with the ld wrapper and it's search paths we'd need it |
126 |
to emit -lstdc++.6 or add another directory deep inside |
127 |
${EPREFIX}/usr/lib to the wrapper's forced search paths - with unknown |
128 |
consequences for all packages. |
129 |
|
130 |
So I've downloaded 600MB of doxygen clang documentation to try to get a |
131 |
handle on whether I can use that GCCInstallationDetector and the Gentoo |
132 |
patch on OS X as well or if I have to duplicate the logic for Darwin. |
133 |
|
134 |
On the other hand we might get away with patching clang so that it puts |
135 |
-l<right name> to the linker and depend on the ld wrapper to sort it |
136 |
out. |
137 |
|
138 |
A proper Gentoo-compatible GCCInstallationDetector for Darwin would be |
139 |
nice though, wouldn't it? |
140 |
|
141 |
> > 5. llvm/clang silently uses the Xcode tools and SDKs to compile its |
142 |
> > runtime libraries. The patch from this bug forces it to use itself (the |
143 |
> > compiler it has just compiled and is about to install) to compile |
144 |
> > those runtimes: https://bugs.gentoo.org/show_bug.cgi?id=537342. This |
145 |
> > disables compliation of all the stuff for ios, however. |
146 |
> Great! another one for the todo list. |
147 |
|
148 |
I'm uncertain what the correct route is to go here: Compiling everything |
149 |
with itself is the right way to go on principle because it avoids |
150 |
weird fallout later on. But throwing away all the iOS stuff just for |
151 |
that seems a bit excessive to me. What's your sentiment on that? |
152 |
|
153 |
There might be a compromise but that would mean replacing all the xc-run |
154 |
calls in the Makefiles so that the SDKs can stay enabled and remain in |
155 |
use but with our freshly built compiler. I think that would make for |
156 |
quite a large patch. |
157 |
|
158 |
> > 1. First check if the include of the offending heder is needed at all. I |
159 |
> > was able to make at least two packages work again by just removing a |
160 |
> > senseless include that was pulling in one of those __has_features. |
161 |
> I'm affraid this is a solution that works only in a very few cases. |
162 |
|
163 |
Yep, but it's the preferable route in the long run. It worked nicely |
164 |
with cctools/ld64 because those suffer from serious include bitrot. |
165 |
|
166 |
> > 2. Define them to nothing as explained here: |
167 |
> > http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros |
168 |
> I remember doing this for some package. I wonder if we shouldn't do |
169 |
|
170 |
gcc-apple for libstdc++. In fact my new 10.10 patch still has that in it. |
171 |
|
172 |
> something with gcc's fixincludes to make this work for GCC by default. |
173 |
> I do feel gcc may be a dead-end for Mac OS X, but FSF-gcc may always be |
174 |
> nice to have from a development perspective. |
175 |
|
176 |
The following mail thread and corresponding bug have some stuff for |
177 |
fixincludes and __has_feature for FSF GCC 4.9 in it: |
178 |
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01402.html |
179 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 |
180 |
|
181 |
But only the deployment target macro stuff seems to have made it into |
182 |
trunk (what I backported to gcc-apple). The bug does however have loads |
183 |
of links to MacPorts that I hadn't spotted before where this fixincludes |
184 |
stuff seems to be in active use. |
185 |
-- |
186 |
bye, |
187 |
Micha |