1 |
On Wed, 25 Jul 2018 23:19:13 +0100 |
2 |
James Le Cuirot <chewi@g.o> wrote: |
3 |
|
4 |
> > Then we could start warning users about the fact of inconsistency and point |
5 |
> > to migration procedure. And we could have cleaner ${CTARGET} matches against |
6 |
> > what Gentoo expects. |
7 |
> |
8 |
> Not sure about this. As I've said, I don't want to force users to |
9 |
> migrate. Would a warning be too annoying? |
10 |
|
11 |
I don't know where to put the warning yet. It thought of it as a longer-term plan |
12 |
not as today's change. Still would be nice to have helper today that would tell you |
13 |
that CHOST tuple has unexpected configuration. |
14 |
|
15 |
I would plug new helper's output as an 'einfo' into gcc and glibc packages :) |
16 |
|
17 |
> > 5. you don't use ${CFLAGS} here. I feel we should use them as people do occasionally |
18 |
> > override defaults. |
19 |
> |
20 |
> I considered it but can we reliably get the flags for CTARGET? |
21 |
|
22 |
Maybe not. |
23 |
|
24 |
On second thought let's not peek into users' CFLAGS. They are too volatile |
25 |
WRT user settings from emerge run to run. Let's sanitize toolchain defaults here. |
26 |
|
27 |
> > I suggest using *-gnueabihf. I don't think anything more generic is recognized by toolchains |
28 |
> > as a hardfloat target. |
29 |
> |
30 |
> There is also musleabihf and uclibceabihf. Would *eabihf be better? |
31 |
|
32 |
Good catch! Yes, -*eabihf is better. clang supports at least |
33 |
lib/Support/Triple.cpp: .StartsWith("eabihf", Triple::EABIHF) |
34 |
lib/Support/Triple.cpp: .StartsWith("gnueabihf", Triple::GNUEABIHF) |
35 |
lib/Support/Triple.cpp: .StartsWith("musleabihf", Triple::MuslEABIHF) |
36 |
|
37 |
> > Also please link to description of what you think canonical hardfloat tuples are supposed to |
38 |
> > be. Upstreams do not agree on the definition. |
39 |
> |
40 |
> I thought this was basically dictated by our profiles but okay. |
41 |
|
42 |
The whole excercise is to attempt to unbreak clang/gcc/other-distros |
43 |
interoperability. Is that correct? At least it's how I see need for change at all. |
44 |
|
45 |
Given that there is no explicit meaning attached to CHOST string anywhere |
46 |
we need a clear description what hardware/abi Gentoo tries to target. |
47 |
|
48 |
Profiles don't say anything about the meaning of CHOST string. They just use it. |
49 |
|
50 |
I'll clarify the question: what do given profile CHOST actually supposed to mean |
51 |
in terms of toolchain parameters? |
52 |
|
53 |
Example answers to the following parameters: |
54 |
- ABI |
55 |
- FPU ABI |
56 |
- minimal ARM ISA instruction set (integer) |
57 |
- assumed FPU ISA |
58 |
|
59 |
I'll take armv7a-unknown-linux-gnueabihf as an example in gentoo today: |
60 |
- ABI |
61 |
- gcc/clang: eabi |
62 |
- FPU ABI |
63 |
- gcc/clang: VFP |
64 |
- minimal ARM ISA instruction set |
65 |
- gcc/clang: armv7-a(?) |
66 |
- assumed FPU ISA |
67 |
- gcc: VFPv3 |
68 |
- clang: VFPv3+NEON |
69 |
|
70 |
What do we do about the VFPv3/VFPv3+NEON mismatch? |
71 |
|
72 |
Presence of neon at the very least causes glibc to disable |
73 |
IFUNC handling: https://bugs.gentoo.org/657760 . It's not a bug |
74 |
on it's own and does not cause the problems (I know of) but it's a |
75 |
visible difference. |
76 |
|
77 |
I'll try to add a toolchain page to describe today's Gentoo deviations |
78 |
from gcc's upstream default. |
79 |
|
80 |
armv6 answers to the above will be different. |
81 |
|
82 |
[ not directly related but still a mismatch that will cause problems: |
83 |
PIC/PIE defaults between gcc/clang in gentoo differ on arm as well ] |
84 |
|
85 |
-- |
86 |
|
87 |
Sergei |