avr-libc assumes that the host tuple will be avr (as in avr-gcc, avr-ld, etc). It's common in the avr community, but it's not really correct (should be avr-elf or the like). I've revised the ebuild to add support for the correct case without removing support for the old method. Reproducible: Always Steps to Reproduce:
Created attachment 113833 [details] dev-embedded/avr-libc-1.4.5-r1.ebuild The new ebuild
Created attachment 113834 [details, diff] diff between -r0 and -r1 a diff for easy comparison and application
What's the reasoning behind this other than "i wanna use my own gcc instead of the one built with crossdev"? (which is the path we recommend for cross toolchains).
"avr" is not a tuple, regardless of the fact that crossdev allows it to be built like that. The fact that crossdev needs a "special target" in order to do so illustrates my point. If people want to use it that way, that's fine, but the ebuild should support the correct use.
Sorry but no. I don't wanna get more bugs for the silly uses some user will make of this and thus get bugs, my time is already lacking. Also avr isn't supposed to work in a standard gnu fashion with a standard libc anyway.
CTARGET is the community-wide standard for building cross-compilers. It's also the gentoo-standard way to do it. Every gcc-based cross-compiler I've used has been named correctly, even platforms like the ppc cores inside virtex-4 LX series, and coldfire chips. AVR is the only aberration. I corrected this, while still maintaining backwards-compatibility with the old, incorrect method. In addition, I fixed the stupidity where the ebuild errors out if it cannot find gcc instead of properly DEPENDing on it. This patch is /correct/, and will cause less breakage that the current situation. But it's up to you, obviously. This can join my ever-growing list of ignored patches in my overlay.
