packaging arm-none-eabi toolchain for cross-development for ARM "bare metal" (no Linux kernel) systems

[Eric Smith]

I've made some progress towards packaging up an arm-none-eabi toolchain 
and newlib for cross-development for ARM platforms that do not run Linux 
(vs. the arm-gp2x-linux toolchain).  Is anyone else interested in this?

Currently I've got packages for:
    binutils-2.20
    newlib-1.18.0 bootstrap (only provides the headers needed to compile 
GCC bootstrap)
    gcc-4.4.3 bootstrap (C only, no libraries, to build newlib)

I'm working on packages for:
    newlib-1.18.0 full
    gcc-4.4.3 full (with C++, using newlib)

I expect to start on gdb soon.

What is the preferred method of getting packages with a bootstrap and/or 
circular dependency issue
into Fedora?  What I've done so far is to have newlib and gcc packages 
both with and without "-bootstrap" in the name, and have gcc-bootstrap 
buildrequires newlib-bootstrap.  newlib can build using either 
gcc-bootstrap or gcc, and I'm not sure how to express that in the spec.  
Then gcc will buildrequire newlib.

I've also considered:

    include newlib sources in the gcc-bootstrap package, to avoid the 
need fora  newlib-bootstrap package

    combine bootstrap and normal specs, with a boostrap variable

The folks packaging mingw32 appear to have been through a bootstrap 
issue somewhat like this, but I'm not sure how they resolved it.  The 
part that seems tricky is ensuring that it is possible to rebuild 
starting from just SRPMs, without having any of the binary RPMs.  (I 
assume that is a requirement, but maybe not?)

Any suggestions are welcome.  And if there's a more appropriate mailing 
list to discuss this, I'm all ears.  The Fedora Embedded SIG page in the 
wiki didn't mention a mailing list.

Thanks,
Eric