AVR target patch

[Gedare Bloom]

Ralf,

Do you have any concerns with these modifications to the build system
M4 macros? They seem pretty straightforward to me to allow use of a
non "rtems"-branded toolchain.

-Gedare

On Sat, Apr 6, 2013 at 7:35 PM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu> wrote:
> Hi,
>
> Please review this patch, and consider it for submission. It allows avr-gcc to attempt to compile RTEMS.
>
> As I was exploring getting the avr port to be not as reliant on newlib, I came across the following issues:
> 1. the build system rejects all non-rtems toolchains, which is an issue because avr-gcc is carefully avoiding modifying the avr-rtems toolchain, so when avr-gcc is fixed for avr-libc, avr-rtems4.11-gcc is neither broken nor fixed.
> 2. the build system verifies newlib is POSIX compliant every time configure is run (even with --disable-posix)
> 3. after issues 1+2 are addressed avr-gcc builds all of the cpu-kit except up to score, which it's missing struct timeval.
>
> Below is a patch that addresses issue 1. I checked, and it doesn't affect non-avr targets.
>
> Issue 2 is slightly larger in scope, so I'll need to see which headers, declarations, etc, are needed by the existing header files.
>
> I'll probably skip issue 2 and move on to issue 3.
>
> FWIW: I'm working on updating the avr port of RTEMS, and know there is interest in getting a lower-memory footprint for the avr port. Another goal of the update is to use a tool-chain that is being actively maintained.
> The avr port has the modified BSD licensed avr-libc as a build requirement.
>
> Thanks,
> Cynthia Rempel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>