| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
after 5.4-RELEASE.
|
|
|
|
| |
Ports Collection documentation and use 'ARCH' rather than 'MACHINE_ARCH'.
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
| |
where we can't build the docs.
Hinted by: kris
|
|
|
|
|
|
| |
sufficiently current version of FreeBSD.
Submitted by: vs
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
aren't up-to-date for GCC these days.
Also, document the 0b binary constants hack committed a few hours ago.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Submitted by: trevor
Tested by: bento
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Approved by: joerg (maintainer)
|
| |
|
|
|
|
| |
fixes have been made to gcc recently.
|
|
|
|
|
|
|
| |
Requiem mors pacem pkg-comment,
And be calm ports tree.
E Nomini Patri, E Fili, E Spiritu Sancti.
|
|
|
|
|
|
| |
patch by the avr-gcc maintainers.
Bump portrevision for that.
|
|
|
|
| |
of the head of CVS.
|
|
|
|
|
|
|
| |
${PORTSDIR}/lang/perl5 as a dependency.
Sponsored by: Porta Software Ltd
Approved by: portmgr
|
|
|
|
| |
about the incorrect pkg-plist made in rev 1.17.
|
|
|
|
|
|
| |
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 `.'.
|
| |
|
|
|
|
|
| |
Since the system's perl in -stable is too old (pod2man), we supply
pregenerated man pages in a separate distfile to help them out.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
port since avr-libc-current has avr-gcc 3.3 as their prerequisite.
|
|
|
|
| |
re-installing avr-c++filt which is already present from avr-binutils.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
microcontroller, but i got interested to get a complex FFT working.
No stdlibc++ support at this time.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Submitted by: bsd
|
|
|
|
| |
location. Current list stolen from lang/gcc-devel.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|