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