A ports freeze means that commits will be few and far between and only by approval.

Number of commits found: 67

Add plist files forgotten in last update.

Reminded by:    pav

Add support for ATtiny88, ATmega32HVB, ATmega1284P.
Fix support for AT90USB82/162, move them into "avr35" architecture.
Add support for the OS_main and OS_task attributes.

Integrate some more bugfixes from the WinAVR patch list.

Upgrade to GCC 4.2.2

Migration from bison 1.x to 2.x

PR:             117086
Tested by:      -exp runs

Welcome bsd.perl.mk.  Add support for constructs such as USE_PERL5=5.8.0+.
Drop support for antique perl.

Work done by:   gabor
Sponsored by:   Google Summer of Code 2007
Hat:            portmgr

Add device support for ATmega8HVA/ATmega16HVA.

Change AT90USB82 from avr5 to avr5.

Add the Russian message catalog file to pkg-plist.

Minor fix for AT90USB* devices.

Submitted by:   Anatoly Sokolov

Also spell-fix `PORTREVISION' *blush*.

Fix pkg-plist after version upgrade.

Reminded by: pointyhat.

Upgrade to GCC 4.1.2.

Add support for AT90PWM1, ATmega32[59]0?P, AT90USB82/162.

OK, I bite.  Implement the patch from PR ports/96407, to avoid the
-mcpu=foobar braindeadness.

There's a GCC bug open for this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
so at least, the issue is being dealt with in its origin.

Submitted by:   Alex Mogilnikov <alx@intellectronika.ru>
PR:             ports/96407

Copy over the avr-gcc-devel port to avr-gcc, so this will become the
default AVR-GCC version now.

No repocopy as this port used to exist before.  For the history details,
see the old avr-gcc-devel port (going to be moved to Attic now).

devel/avr-gcc has been repocopied to devel/avr-gcc-3, so to make room
for devel/avr-gcc-devel taking over the role of the default AVR-GCC
port now.

Fix the link specification in the patch so ATmega*P devices will get
their correct -Tdata option passed down.

Submitted by:   Anatoly Sokolov

Rename ATmega164/324 to ATmega164P/324P, add support for ATmega644P,
ATmega165P, and ATmega169P.

Upgrade to GCC 3.4.6.
Add support for ATmega406 and AT90USB646/647/1286/1286 devices.
Register conflict for avr-gcc-devel port (GCC 4.1-based, to come soon).

Fix the severe bug (faulty code generation) reported in

<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118>

by reverting the GCC change that obviously caused it.

Approved by:    portmgr (krion)

Add support for ATtiny261/461/861.

Upgrade to GCC 3.4.5, and add support for ATtiny24/44/84 devices.

Mass-conversion to the USE_AUTOTOOLS New World Order.  The code present
in bsd.autotools.mk essentially makes this a no-op given that all the
old variables set a USE_AUTOTOOLS_COMPAT variable, which is parsed in
exactly the same way as USE_AUTOTOOLS itself.

Moreover, USE_AUTOTOOLS has already been extensively tested by the GNOME
team -- all GNOME 2.12.x ports use it.

Preliminary documentation can be found at:
        http://people.FreeBSD.org/~ade/autotools.txt

which is in the process of being SGMLized before introduction into the
Porters Handbook.

Light blue touch-paper.  Run.

Add support for the AT90CAN32/64 controllers.

By the same time, also drag in the patch for catching
misspelled interrupt vector names from the 4.x branch of
GCC.

Add support for the ATmega640/1280/1281 family.

Oops, a double slash sneaked into the linker spec, causing GCC to
recurse infinitely, until it hit an abort().

Add back support for the ATmega165.

Fix the linker command (in GCC's specs file) for the AT90PWM2/3
controllers.

Approved by:    portmgr (linimon)

Upgrade AVR-GCC to GCC-3.4.4.

By the same time, combine all the patches that add support for new AVR
devices into a single patch, as they all touch the same three source
files.  In total, add support for the following AVR devices that were
not supported by the stock GCC 3.4.x:

  ATtiny13/ATtiny2313
  ATtiny25/ATtiny45/ATtiny85
  ATmega48/ATmega88/ATmega168
  AT90PWM2/AT90PWM3
  ATmega164/ATmega324/ATmega644
  ATmega325/ATmega3250/ATmega645/ATmega6450
  ATmega329/ATmega3290/ATmega649/ATmega6490
  AT90CAN128

(This is now documented in pkg-descr as well.)

At Kris's request, back out the MACHINE_ARCH spelling correction until
after 5.4-RELEASE.

Assist getting more ports working on AMD64 by obeying the
Ports Collection documentation and use 'ARCH' rather than 'MACHINE_ARCH'.

Bring in some patches from the head of GCC's CVS back to the latest
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).

Do also set IGNORE when running against a too old version of Perl
where we can't build the docs.

Hinted by:      kris

Require a sufficiently current Perl to be installed, as opposed to a
sufficiently current version of FreeBSD.

Submitted by:   vs

Upgrade to GCC version 3.4.3.

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.

Switch from MASTER_SITE_GNU to MASTER_SITE_GCC; it seems the GNU mirrors
aren't up-to-date for GCC these days.

Also, document the 0b binary constants hack committed a few hours ago.

Upgrade AVR-GCC to GCC 3.4.1.

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.

Sync with new bsd.autotools.mk

Upgrade to GCC 3.4.0.

This also makes the port compile (again) under all 64-bit archs.  For
amd64, patch-ad modifies config.guess to match GCC's expectation of
x86_64.

BROKEN on !i386 and !alpha: Does not build

Upgrade to version 3.3.2.

Add USE_GETTEXT and bump PORTREVISION.

Submitted by:   trevor
Tested by:      bento

Now gettext 0.12.1 is gettext-old.

Update this port to the released version 3.3.1 of gcc.

Utilize INFO while i was at it.

Some minor cosmetic issues are still open with this port, but i won't
be able to catch that before the ports freeze.

Fix COMMENT.

Approved by:    joerg (maintainer)

Update to a recent snapshot.  Some AVR-related bugs have been fixed since.

Update this suite to a current snapshot of gcc 3.3.  Quite a few AVR-related
fixes have been made to gcc recently.

Clear moonlight beckons.
Requiem mors pacem pkg-comment,
And be calm ports tree.

E Nomini Patri, E Fili, E Spiritu Sancti.

Replace my old 16 bit IO register assignment hack by an authoritative
patch by the avr-gcc maintainers.

Bump portrevision for that.

Update to a more recent snapshot, now taken from gcc's 3.3 branch instead
of the head of CVS.

Use USE_PERL5_BUILD where appropriate, instead of hardcoding
${PORTSDIR}/lang/perl5 as a dependency.

Sponsored by:   Porta Software Ltd
Approved by:    portmgr

Add the forgotten dependency to gettext.  This fixes the complaint
about the incorrect pkg-plist made in rev 1.17.

Update to a recent snapshot.  Among others, this fixes an issue with
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 `.'.

BROKEN: pkg-plist is incorrect

Fix the documentation build process.  We need to depend it on perl.
Since the system's perl in -stable is too old (pod2man), we supply
pregenerated man pages in a separate distfile to help them out.

Update to version 2002.09.01.  Included are a couple of private
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.

Now that gcc renamed the head of their CVS from 3.2 to 3.3, update this
port since avr-libc-current has avr-gcc 3.3 as their prerequisite.

Mega-upgrade of the AVR GNU toolchain, step #2:
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.

Fix packaging list.

Update to gcc 3.0.1.    

Include the C++ compiler.  Certainly of limited use for a   microcontroller, but
i got interested to get a complex FFT working.    

Ooops, the PKGNAMEPREFIX got accidentally dropped.    

Upgrade to the released version of gcc 3.0.    

This gcc snapshot requires bison in order to build.    

I forgot to update the master sites accordingly for the gcc snapshot   location.
 Current list stolen from lang/gcc-devel.    

Upgrade to a development snapshot of gcc-3.  Target `avr' is now   supported
natively, so no external patches needed anymore.    

Finally get the avr-gcc port really compile on the alpha architecture,   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.    

Argl.  USE_AUTOCONF wasn't quite what i actually intented...  Instead,  
manually add the dependency for autoheader(1), but don't have the ports  
infrastructure run `autoconf' (which clobbered the top-level configure  
script).    

Didn't notice before that this port actually uses GNU autoconf...  This   should
fix the port build on bento.    

Atmel AVR cross-development, part #2: the C compiler.    

Number of commits found: 67

9 vulnerabilities affecting 22 ports have been reported in the past 14 days

^* - modified, not new

All vulnerabilities