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

[Denis Chertykov]

2015-02-20 14:56 GMT+03:00 Georg-Johann Lay <address@hidden>:
> 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.