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

Am 02/23/2015 um 05:21 AM schrieb Senthil Kumar Selvaraj:
> 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.

I just updated to trunk r2467 and it appears to work with gcc trunk.

I'd expect that if no "avr-libc with new layout" is present then avr-gcc would 
fallback to the old-style default specs and would use its device information 
from avr-mcus.def, avr-arch.h, avr-devices.c et al.?

>> Or am I missing something fundamentally like new configure options?
>
> No, no new configure options have been added.

Am I right in that

i) avr-gcc < 5 won't work with new avr-libc ?

ii) avr-gcc >= 5 won't work with old avr-libc ?

iii) avr-gcc >= 5 won't work with, e.g. newlib, even if configured with 
--with-avrlibc=no ?  I.e. avr-gcc will no more support newlib / rtems ?


>> 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?

It's clear what specs are and how they work.

My question was w.r.t. which part of the toolchain supply the new files, what 
the naming conventions are (i.e. "m8 for ATmega8) and what has to be done to 
make these changes transparent.  "the steps to build the toolchain will be just 
as before" is no more true if I use avr-gcc-5 + newlib or avr-gcc-4.9 + current 
avr-libc.

If any of the avr-gcc / libc combinations which worked well with previous 
versions cease to work with new avr-gcc and / or new avr-libc this should be 
mentioned in the GCC release notes caveates.  Even more preferred is to factor 
out the incompatibilities by means of gcc / avr-libc configury, e.g. to adjust 
--with-avrlibc so that it works again as expected or switch to old-style layout 
if avr-gcc sees old-style avr-libc or newlib.  This could be done by 
--with-avr-libc=2.0 or so.


>> 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.

Maybe it's better the other way round, i.e. let avr-gcc detect what libc 
flavour is (or will be) present.  That way it can also work with newlib again.


As this is a big change in avr-libc which also requires changes in other parts 
of the toolchain, it might justify to switch to a new mayor version of avr-libc 
like 1.9 or even 2.0.

>> [...]
>>
>> 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