the generation of code that fed up recent versions of gas. The
pseudo-symbol _PC_ is now completely eliminated from the generated
code, and replaced by the location counter `.'.
patches that were floating through the avr-gcc and avr-libc
mailinglists, just for the time being until they might have been
integrated into gcc's CVS.
Portname changed from dashes in the snap date to dots so portupgrade
doesn't get confused about it. Thanks to Brian Dean for the hint.
Upgrade to a development version of GCC 3.2. New AVR microcontrollers are
introduced with faster pace than new versions of GCC :), so we need the
development version to support recent AVR chips (like the ATmega 128).
Alas, official GCC snapshot tarballs still track the 3.1.x branch, so i
got to CVS checkout and roll my own tarball.
supported natively, so no external patches needed anymore.
Note that this port requires up-to-date avr-binutils, since a few things
in the assembler syntax have been changed.
Not yet tested on the alpha platform.
by forcing the CFLAGS to -O -pipe. Somehow, the alpha build always
tries to enforce a particular -mcpu=ev4 flag which of course cannot be
understood by the (AVR) xgcc later on. This looks to me like a bug in
the cross-compilation environment of gcc, but i'm tired of actually
finding the bug.
The compiled result of avr-gcc MD5 compares equal to something build
from an IA32 host platform.
Since gcc (in the assumption of generating a native compiler) doesn't
want to cbe configured for an alpha*-*-freebsd* system, we hack the
configure script to allow this (similarly to netbsd). In the end, all
this will be ignored anyway since it's getting to become a
cross-compiler.
manually add the dependency for autoheader(1), but don't have the ports
infrastructure run `autoconf' (which clobbered the top-level configure
script).
should fix the port build on bento.
Still doesn't want to be built on the alpha arch, i'm not sure whether
i'll be able to fix that or whether i'll have to exclude it from the
alpha build. In theory, since it's a cross-compiler already anyway, it
should be possible to build it on non-i386 platforms as well.
