Re: Strategy for packaging an ARM Cortex-M toolchain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



[Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Home]     [Fedora Tools]     [Fedora PHP Devel]     [Kernel List]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

Add to Google Powered by Linux