released version, 3.4.3. This mainly adds support for new AVR devices
that appeared on the market recently, and fixes a bug related to the
order of assignments for volatile uint16_t * objects (in the
assumption they might point to IO space where the order of two 8-bit
operations can be important).
Note that I do not longer support FreeBSD 4.x at this point, as their
system-provided Pod::Man is way too old, and I'm tired of rolling that
extra man page tarball. Software developers can IMHO reasonably be
expected to run some version of FreeBSD 5.x these days.
Also included is a local hack to allow for 0bXXX binary constants,
since this appears to be a frequently requested item in the AVR
developers community.
The GCC configuration is tuned to allow for both, -gstabs [the default
if only -g is given], and -gdwarf-2 debugging options. ELF/DWARF-2 is
the emerging format as promoted by Atmel, and is intented to be
directly usable in their AVR Studio simulator in future. Eventually,
AVR-GDB will fully support DWARF-2 debugging as well some day.
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.
