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 (http://koji.fedoraproject.org/koji/packageinfo?packageID=12980) as a means of packaging the tools so you don't mess with the normal gcc, binutils, etc installed on the machine.
-Will
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
