Using the least common denominator is another food reason to consider link
time optimization... I wonder if e.g. fatelf would make it easier to
implement that. Multiple arm binaries glued together based on variant and
hwcaps (e.g. v6+vfp-d16, v7+vfp-d32, v7+neon)? Heck, if fatelf were used,
only one stage3 tar ball would be necessary for all arch's combined...
although downloading would be significantly slower :-/

©

Sent from my Android
On May 18, 2012 1:10 AM, "Mike Frysinger" <vapier@gentoo.org> wrote:

> currently, we have the system:
>         - if chost matches *-softfloat-*, you get softfloat
>         - if chost matches *-hardfloat-*, you get hardfloat
>         - for everything else, you get the gcc default
>
> with the standardization work going on with armv7+ and hardfp, i've made
> the
> following change:
>         - if chost matches armv7*-softfloat-*, you got softfloat
>         - for all other armv7* targets, you get hardfloat vfp3-d16
>
> along those lines, i've also slipped in:
>         - if chost matches armv6*-softfloat-*, you got softfloat
>         - for all other armv6* targets, you get hardfloat vfp
>
> considering vfp is required baseline in these cores now, it doesn't make
> sense
> to not use it if the user has explicitly stated they're targeting these
> arches.
>
> if you really want to use a different default, you can still use
> EXTRA_ECONF to
> set whatever you want.
> -mike
>