On Fri, Feb 20, 2015 at 12:56:59PM +0100, Georg-Johann Lay wrote: > 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?
The patches to avr-libc to build and place crt1.o and libdev.a in the correct locations were submitted to the patch tracker a while back. Those patches involve non-trivial changes to the build machinery of avr-libc, so we were hoping for some feedback before it gets committed. There's been none so far, so I guess we'll go ahead and commit the changes. > > Or am I missing something fundamentally like new configure options? No, no new configure options have been added. > > More specifically: > > 1) Where is the (internal) documentation of all of this? Once the patches land in avr-libc trunk, the steps to build the toolchain will be just as before. Or do you mean documentation on how the specs based mechanism works? > > 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? We're planning to make avr-libc detect and fallback to the current layout if it detects and older gcc version. > > 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. Sorry about that - we'll fix this ASAP. > > 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. Agreed. Would you prefer temporarily committing the change I suggested (http://lists.nongnu.org/archive/html/avr-gcc-list/2014-10/msg00028.html) until all the changes land in avr-libc? > > 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 > > _______________________________________________ > AVR-GCC-list mailing list > AVR-GCC-list@nongnu.org > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
