Previous discussions (and my examples) on cross-compiling were focused on other operating systems: MinGW, Linux, and Solaris. But there is another use of cross-compiling: "bare metal" embedded systems. Yesterday I built my first example of such: the AVR toolchain, a sample build of which is now alongside the others:
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/ Two issues arose when dealing with AVR: 1) cygport had been fully canonicalizing triplets, so "avr" became the oh-so-informative "avr-unknown-none". Fedora and Debian both use just "avr", as that naming is expected by the toolchain. These seem to be common with embedded systems, so I changed cygport to remove "-unknown" and "-none" from triplets. 2) While sysroots make sense for full-OS cross-compiles, where one needs a location to hold a number of cross-compiled libraries arranged as if on a native system, it seems not to be the case for embedded systems. AFAICS with AVR, programs are more unique to the board and most general-purpose software isn't meant to compile against avr-libc (or is it the other way around?). So having /usr/avr/sys-root/usr/{include,lib} seemed wrong for two reasons: a) there is no comparable "native" /usr/{include,lib} on a bare-metal system, and b) using a sysroot just for avr-libc seemed a bit overkill. The alternative is to not build binutils/gcc with sysroots, configure avr-libc (and same goes for newlib on $cpu-elf embeddeds) with --prefix=/usr and let them install into /usr/$arch/{include,lib} as they are designed. This is also how they are packaged on Fedora and Debian (even though Fedora does use sysroots for mingw*). Now I have ZERO experience with embedded systems, so I could be way off on my assessments here. Can anybody that *does* have some experience with these provide some further insight? Furthermore, for which systems should this apply? Yaakov