1 |
Am 27. Oct 2014, 11:14 schrieb Alexis Ballier <aballier@g.o>: |
2 |
|
3 |
> By the way, any help for maintaining the libc++ stack is very welcome; |
4 |
> as you can see from the age of the current snapshots, it's been some |
5 |
> time I've not been playing with it. |
6 |
> |
7 |
> |
8 |
> Some notes: |
9 |
> - why not adding a clang subprofile ? there's one for amd64-fbsd; I had |
10 |
> been able to build a complete stage 3 without too much trouble. |
11 |
> There's probably nothing bsd specific there, so moving |
12 |
> generic code from there to profiles/features should work. |
13 |
|
14 |
Yes, it looks fairly generic. This is definitely worth a try. |
15 |
|
16 |
> - it'd be worth fixing/improving libunwind support, esp. as you write |
17 |
> here on the clang 'spec' parts; I don't remember if there were other |
18 |
> issues, but it was a bit pointless if we can't get rid of libgcc_s |
19 |
> because of clang (maybe there were even symbol collisions?) |
20 |
> - libcxxabi is probably the new way to go instead of libcxxrt; last |
21 |
> time I checked there was a chicken and egg problem: libcxxabi needed |
22 |
> clang + libc++ to build, so bootstrapping the stack was a bit |
23 |
> painful. |
24 |
|
25 |
The Toolchain behavior on GNU/Linux is fairly tailored to using gcc at |
26 |
the moment (just grep for gcc_ on |
27 |
tools/clang/lib/Driver/{Tools|Toolchain}.cpp). |
28 |
|
29 |
In order to really pull off a clang/libc++ toolchain independent of gcc |
30 |
assistance would involve quite a bunch of (preferably upstream) work... |
31 |
|
32 |
> - there are a few todos in libcxx ebuild (mainly libsupc++ support, but |
33 |
> the same could apply to libcxxabi) |
34 |
> - it'd be interesting to have stand-alone ebuilds for gcc's crt files; |
35 |
> or better, find BSD-like alternatives |
36 |
> |
37 |
> Alexis. |
38 |
|
39 |
Best, |
40 |
Matthias |