avr-gcc still broken because of new device specific specs and libs

avr-gcc is still broken and fails to compile trivial programs:


$ avr-gcc-5.0 -mmcu=atmega8 main.c
/local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot 
find dev/atmega8/crt1.o: No such file or directory
/local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot 
find dev/atmega8/libdev.a: No such file or directory
collect2: error: ld returned 1 exit status

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr 
--prefix=/local/gnu/install/gcc-5.0 --disable-shared --disable-nls 
--with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld 
target_alias=avr --enable-languages=c,c++

gcc version 5.0.0 20150216 (experimental) (GCC)


I just updated my sources and built / installed

- GCC configured for avr (trunk)
- Binutils configured for avr (master)
- AVR-Libc (trunk)


This situation persists for several months now, since around october '14 or so.


When will this be fixed?

Or am I missing something fundamentally like new configure options?

More specifically:

1) Where is the (internal) documentation of all of this?

2) What must I do to get a working toolchain?

3) What must I do to get a working build directory, e.g. for running testsuite 
against a freshly built and not yet installed compiler?

4) If this stuff is not (completely) hosted in GCC repo, what has been done 
(e.g. GCC configury) so that older GCC versions factor out the presumably now 
incompatible dependencies?  In particular:  How is ensured that avr-gcc 4.9, 
4.8 etc. will still build and work as expected with such external dependencies?

5) Are these extensions hosted in a different place? I.e. is avr backend no 
more supported by the FSF or forked and FSF code base messed up by half-baked 
changes?  Or is hardware vendor simply half-hearted about state of avr-gcc?


The current situation is that it's almost impossible to contribute to avr-gcc 
because it's impossible to run tests against patches.

Applying additional patches or hacks to get it linking is actually no solution 
because that will invalidate test results as tests won't run against the 
intended patch but against a completely different delta.

If nobody is inclined to complete the device-specs / device-libc then I will 
propose to revert these changes in order to get a working avr-gcc 5.0.


Johann