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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
