hello debian gcc maintainers, i'd need your help to proceed with an itp of mine (bug #691349) for libopencm3, which is a firmware library for embedded arm cortex devices (the kind that's too small to run linux). from the itp's shortcomings section: > * it depends on something to provide arm-none-eabi-gcc and an > appropriate libc (eg newlibc). > > currently, i'm using a popular script to download, compile and install > the required toolchain: summon-arm-toolchain[2] (by the libopencm3 > authors), for which i wrote a little debian directory[3] -- in that > form, it's pretty inacceptable as a debian package, though. and from the "what i need" section: > * an idea of how to create an arm-none-eabi-gcc package properly. > my gut feeling says that the gcc-4.[67] packages should build another > binary package called gcc-4.[67]-arm-none-eabi, similar to > gcc-4.6-hppa64. i'm not familiar with how gcc actually works, so i > wonder whether we could have a gcc-4.7-multiarch just like we have > binutils-multiarch (which works well for libopencm3). same goes for > gdb (not depended on, but more "essential" than "useful" to > developers) > > * a packaged newlibc; given how libstdc++ is integrated with gcc, i > don't know whether that's separate from the above or not. so my questions to you in particular are: * would it be reasonable to have the gcc packages build something with arm-none-eabi-gcc too? * if not, what are your recommendations on packaging? do you think it'd be useful to take the approach of avr-gcc? * newlib is packaged independently as a package, would a gcc-arm-none-eabi package require any kind of tight integration or can i treat those issues separately? i'd appreciate your comments and suggestions chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
Attachment:
signature.asc
Description: Digital signature