Strategy for packaging an ARM Cortex-M toolchain

[Ralf Corsepius]

On 05/23/2012 06:07 PM, Rob Spanton wrote:
> Hi,
>
> There are an increasing number of ARM Cortex-M based boards around, and
> I'd like to get a cross-compilation toolchain for them into the Fedora
> repositories.  I'd like to make it just as easy to compile for Cortex-M
> chips under Fedora as it is to compile for AVR or MSP430 targets right
> now (i.e. `yum install ...`).
>
> So I've cobbled together packages for a prototype toolchain [1],
> consisting of binutils, gcc, newlib and gdb.  Currently with the
> target-triplet "arm-none-eabi", which I think I'll be changing to
> "arm-cortex_m-eabi".
>
> I'd like to avoid this toolchain conflicting with, or duplicating the
> effort put into other cross-compilation toolchains that are currently in
> Fedora.
>
> There are two things that I can think of that this cortex-m3 toolchain
> might interact with at the moment:
>       1. The arm-gp2x-linux toolchain currently in the repositories.
>       2. Any cross-compilation toolchains generated by the Fedora ARM
>          {primary,secondary} architecture stuff that's happening.
>
> I think the binutils and gdb builds for these things would be
> practically identical to the cortex-m one.  So it might be sensible for
> them to share the same binutils and gdb packages.  Maybe ABI differences
> would make it impossible to use the same gdb, but I'm not sure about
> that.
What you say means these are 2 different targets.

> Since these platforms use different C libraries (the Linux-based ones
> use glibc, and the cortex-m one uses newlib built and optimised for
> cortex-m), it's not possible for these platforms to use the same gcc or
> C library packages.
>
> So is it best to attempt to get one arm-binutils package and remove
> redundancy, or is it going to be more productive to just put up with the
> redundancy for now?
No, this will hardly work and would be a nightmare to maintain.

I recomment to implement 2 separate toolchains with separate packages.

Ralf