1 |
Using the least common denominator is another food reason to consider link |
2 |
time optimization... I wonder if e.g. fatelf would make it easier to |
3 |
implement that. Multiple arm binaries glued together based on variant and |
4 |
hwcaps (e.g. v6+vfp-d16, v7+vfp-d32, v7+neon)? Heck, if fatelf were used, |
5 |
only one stage3 tar ball would be necessary for all arch's combined... |
6 |
although downloading would be significantly slower :-/ |
7 |
|
8 |
© |
9 |
|
10 |
Sent from my Android |
11 |
On May 18, 2012 1:10 AM, "Mike Frysinger" <vapier@g.o> wrote: |
12 |
|
13 |
> currently, we have the system: |
14 |
> - if chost matches *-softfloat-*, you get softfloat |
15 |
> - if chost matches *-hardfloat-*, you get hardfloat |
16 |
> - for everything else, you get the gcc default |
17 |
> |
18 |
> with the standardization work going on with armv7+ and hardfp, i've made |
19 |
> the |
20 |
> following change: |
21 |
> - if chost matches armv7*-softfloat-*, you got softfloat |
22 |
> - for all other armv7* targets, you get hardfloat vfp3-d16 |
23 |
> |
24 |
> along those lines, i've also slipped in: |
25 |
> - if chost matches armv6*-softfloat-*, you got softfloat |
26 |
> - for all other armv6* targets, you get hardfloat vfp |
27 |
> |
28 |
> considering vfp is required baseline in these cores now, it doesn't make |
29 |
> sense |
30 |
> to not use it if the user has explicitly stated they're targeting these |
31 |
> arches. |
32 |
> |
33 |
> if you really want to use a different default, you can still use |
34 |
> EXTRA_ECONF to |
35 |
> set whatever you want. |
36 |
> -mike |
37 |
> |