Strategy for packaging an ARM Cortex-M toolchain

William Cohen wcohen at
Fri May 25 21:56:18 UTC 2012

On 05/23/2012 12:14 PM, Ralf Corsepius wrote:
> 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

Hi, Ralf 

You might look at the scl-utils package in Fedora 17 and 18 ( as a means of packaging the tools so you don't mess with the normal gcc, binutils, etc installed on the machine.


More information about the devel mailing list