eglibc and fun with config.sub
Ulrich Weigand
Ulrich.Weigand at de.ibm.com
Fri Sep 16 14:12:04 UTC 2011
Richard Sandiford <richard.sandiford at linaro.org> wrote:
> David Gilbert <david.gilbert at linaro.org> 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
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
More information about the linaro-toolchain
mailing list