1 |
On 31-01-2015 19:25:43 +0100, Michael Weiser wrote: |
2 |
> > > https://bugs.gentoo.org/show_bug.cgi?id=474748 |
3 |
> > > https://bugs.gentoo.org/attachment.cgi?id=394024 |
4 |
> > I'll try and see if I can add these. I'd love to get into a state where |
5 |
> > we can bootstrap into a fully self-providing clang. |
6 |
> |
7 |
> I've just updated those with my most recent ones. They aren't all that |
8 |
> hackish anymore and tested quite a bit. As always, backporting to older |
9 |
> OS Xes revealed some misconceptions and dependencies. But since they |
10 |
> started life somewhere completely different and were hacked by different |
11 |
> people and finally put on a strict diet by me (dropped multilib stuff |
12 |
> and made them plain, straightforward ebuilds), they might not confirm to |
13 |
> some Gentoo policies. So please feel free to subject them to some |
14 |
> scrutiny. |
15 |
|
16 |
OK! |
17 |
|
18 |
> > > Note how clang++ -stdlib=libc++ is now used to compile ld64 and how ld |
19 |
> > > -v reports LTO support (unfortunately not when called via the |
20 |
> > > binutils-config wrapper but when called directly): |
21 |
> > I'll try to tackle this, I guess it's because we insist on adding |
22 |
> > command line arguments even through you do nothing. |
23 |
> |
24 |
> Come to think of it, I'm pretty sure, it's at least partly Apple |
25 |
> braindeadness at work. The code for option -v in ld64 actually reads: |
26 |
> |
27 |
> fprintf(stderr, "configured to support archs: %s\n", ALL_SUPPORTED_ARCHS); |
28 |
> // if only -v specified, exit cleanly |
29 |
> if ( argc == 2 ) { |
30 |
> const char* ltoVers = lto::version(); |
31 |
> if ( ltoVers != NULL ) |
32 |
> fprintf(stderr, "LTO support using: %s\n", ltoVers); |
33 |
> exit(0); |
34 |
> } |
35 |
> |
36 |
> I guess, once upon a time, they wanted to exit immediately if called |
37 |
> with only -v and then someone stuck the LTO support message into the |
38 |
> wrong code block. So now they only inform about LTO support if *only* -v |
39 |
> was given and they're gonna exit. Worse: Some braindead script somewhere |
40 |
> *will* expect it to behave that way. So basically the only thing to be |
41 |
> done is to make the wrapper not add any additional options if it itself |
42 |
> was called with only -v. |
43 |
|
44 |
This should be doable. Why not, eh? :) |
45 |
|
46 |
> > > There is a patch in a bug that lifts that limitation: |
47 |
> > > https://bugs.gentoo.org/show_bug.cgi?id=537826. With that in place in |
48 |
> > > the gcc ebuild and recompiled gcc you can override |
49 |
> > I'll apply this and lift the awkward limitation. |
50 |
> |
51 |
> This might need to be done in quite some steps: Can you have a |
52 |
> dependency in a profile on a certain package version being installed |
53 |
> *before* the new profile is used? Otherwise we'd have to wait until |
54 |
> everyone has updated their gcc-apple before setting |
55 |
> MACOSX_DEPLOYMENT_TARGET to 10.10. |
56 |
> |
57 |
> Also: I found that ld64 from binutils-apple-4.3 doesn't understand 10.10 |
58 |
> as a deployment target either. I've backported the fix from 6.1 and have |
59 |
> an updated ebuild. A new bug for that should pop up in a couple of |
60 |
> hours, I think. But that would still become 4.3-r1, I guess, so that we'd |
61 |
> need to require people to update their binutils-apple as well before |
62 |
> changing the deployment target in the profile. |
63 |
> |
64 |
> On a positive note: I've had the ld wrapper that doesn't add |
65 |
> -macos-version-min to the linker command line in use for some time and |
66 |
> haven't had any fallout yet with or without deployment target being set |
67 |
> to 10.10. |
68 |
|
69 |
I disagree. A crude hack was put in place to make 10.10 support sort of |
70 |
going. We can make all necessary changes to get it bootstrapping, |
71 |
although they may feel (and will be) disruptive. |
72 |
|
73 |
> A proper Gentoo-compatible GCCInstallationDetector for Darwin would be |
74 |
> nice though, wouldn't it? |
75 |
|
76 |
Yes :) |
77 |
|
78 |
> > > 5. llvm/clang silently uses the Xcode tools and SDKs to compile its |
79 |
> > > runtime libraries. The patch from this bug forces it to use itself (the |
80 |
> > > compiler it has just compiled and is about to install) to compile |
81 |
> > > those runtimes: https://bugs.gentoo.org/show_bug.cgi?id=537342. This |
82 |
> > > disables compliation of all the stuff for ios, however. |
83 |
> > Great! another one for the todo list. |
84 |
> |
85 |
> I'm uncertain what the correct route is to go here: Compiling everything |
86 |
> with itself is the right way to go on principle because it avoids |
87 |
> weird fallout later on. But throwing away all the iOS stuff just for |
88 |
> that seems a bit excessive to me. What's your sentiment on that? |
89 |
|
90 |
I prefer to have a functional toolchain first. Developement for iOS is |
91 |
much better done with Apple's official support tool: Xcode. Honestly, |
92 |
they'll know best how/what to do it. |
93 |
|
94 |
> There might be a compromise but that would mean replacing all the xc-run |
95 |
> calls in the Makefiles so that the SDKs can stay enabled and remain in |
96 |
> use but with our freshly built compiler. I think that would make for |
97 |
> quite a large patch. |
98 |
|
99 |
Yes, but IMO we can delay that. |
100 |
|
101 |
> > > 2. Define them to nothing as explained here: |
102 |
> > > http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros |
103 |
> > I remember doing this for some package. I wonder if we shouldn't do |
104 |
> |
105 |
> gcc-apple for libstdc++. In fact my new 10.10 patch still has that in it. |
106 |
> |
107 |
> > something with gcc's fixincludes to make this work for GCC by default. |
108 |
> > I do feel gcc may be a dead-end for Mac OS X, but FSF-gcc may always be |
109 |
> > nice to have from a development perspective. |
110 |
> |
111 |
> The following mail thread and corresponding bug have some stuff for |
112 |
> fixincludes and __has_feature for FSF GCC 4.9 in it: |
113 |
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01402.html |
114 |
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 |
115 |
> |
116 |
> But only the deployment target macro stuff seems to have made it into |
117 |
> trunk (what I backported to gcc-apple). The bug does however have loads |
118 |
> of links to MacPorts that I hadn't spotted before where this fixincludes |
119 |
> stuff seems to be in active use. |
120 |
|
121 |
Oh, that's nice. Maybe we can ste^Wborrow that :) |
122 |
|
123 |
|
124 |
-- |
125 |
Fabian Groffen |
126 |
Gentoo on a different level |