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

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
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list