2015-02-20 14:56 GMT+03:00 Georg-Johann Lay <a...@gjlay.de>: > 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?
Generally, I think that here (on AVR land) FSF is me. (or no FSF at all because I'm not FSF employee. I'm just a contributor and maintainer) I do not know anything about the hardware vendor. I never had any relationship with the ATMEL. Probably I have approved wrong or incomplete patch. (If it's not a GCC core patch) It seems that problem is in generation of `t-multilib' by `genmultilib.awk '. > > > The current situation is that it's almost impossible to contribute to > avr-gcc because it's impossible to run tests against patches. Why ? > > 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 you can provide a patch to fix the bug then please do it. > 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. Which changes ? If you have a solution then please provide it. If not then I will investigate the problem but it takes a time. Denis. PS: I'm slow because a bit demotivated for these 17 years. It's not a big structure. It's you, me, Joern and a few other people. No FSF, no ATMEL, no GCC core people. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
