eglibc and fun with config.sub

Ulrich Weigand Ulrich.Weigand at
Fri Sep 16 14:12:04 UTC 2011

Richard Sandiford <richard.sandiford at> wrote:
> David Gilbert <david.gilbert at> writes:
> > My current patch:
> >   * adds armv6 and armv7 to config.sub
> >   * adds arm/eabi/armv7 and arm/eabi/armv6t2   and one assembler
> > routine in there.
> >   * If $machine is just 'arm' then it autodetects from gcc's #defines
> >   * else if $machine is armv.... then that's still $machine
> I'm taking you literally here, but I think you want things like
> armeb-linux-gnueabi to be treated like arm-linux-gnueabi.
> TBH, I think unconditionally using the autodetect (but setting $machine
> rather than $submachine, as you say) would be easier and more consistent
> across packages.  gcc and eglibc will then agree on the target, whereas
> the extra complication in the current scheme is there simply to make
> eglibc and gcc disagree in certain cases.  But I realise we might not
> want to fight that fight.

FWIW I'd tend to agree that encoding the architecture level into the
target triplet seems to lead to more confusion than that it helps ...

We certainly never did that on s390 (or powerpc, for that matter);
instead, the way to select an architecture level is to build your
system compiler to default to that level, and then build all your
system libraries with that compiler; the libraries will detect
the desired architecture level from GCC defines.

On the other hand, given that arm has already gone down the road of
using the target triplet, I guess I can see why it might make sense
to continue that.  In the end, that's for the platform maintainers
to decide ...

Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
  IBM Deutschland Research & Development GmbH
  Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294

More information about the linaro-toolchain mailing list