[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] Sorry...
RE: [avr-gcc-list] Sorry...
Tue, 06 Nov 2001 11:50:17 -0800
> Maybe I should have mentioned that I use
> the AVR-GCC for windows (allas, sad but true :-) ),
> I downloaded it from http://8-bit.at/avr .
I am not familiar with that version. I am also using avr-gcc on a Windows
I think I may have made things worse for you! I don't know the answer to
your problem. Maybe the version of avr-gcc that you're using is not
compatible with the latest version of libc. Maybe someone else on the list
knows what is going on.
On the other hand, I thought I would tell you how I get avr-gcc up on my
machine in case you want to try it. It ensures that you have the lastest
binutils and gcc and you'll get a system that works with the latest libc. I
have to say, thought, that I don't know if this is feasible with a slow
I use Cygwin (http://sources.redhat.com/cygwin/) to provide a Unix-like
environment on my Windows machine. It's pretty painless since Cygnus
provides the binaries. Then I download the latest CVS sources for binutil
and gcc and make them. Here are some instructions on using CVS to get
binutils sources: http://sources.redhat.com/binutils/. And here are some
instructions on using CVS to get gcc sources: http://gcc.gnu.org/cvs.html.
It can be an involved process, but if you're up to it, I think its a good
way to get avr-gcc running on Windows. I used to use the snapshots
ftp://gcc.gnu.org/pub/gcc/snapshots/), but at some point they stopped
tracking the CVS sources and Marek Michalkiewicz suggested CVS and I've
never looked back.
At the end of this, I've included Marek's posted reply to some of my
questions that got me started with CVS.
From: Marek Michalkiewicz [mailto:address@hidden
Sent: Saturday, May 06, 2000 3:29 AM
Cc: AVR List
Subject: Re: ! synchronize avr-gcc with avr-binutils !
> I have downloaded and built a recent snapshot of binutils:
> and started to build a recent snapshot of gcc:
> The avr-as from this binutils still gives me errors when registers are not
> preceded by an "r".
It seems binutils snapshots (even 000505 - non-Y2K-compliant) still
don't have the CVS changes from 1 May. Strange... So you have to
check out the sources using anonymous CVS. Unfortunately it's a pain
unless you have fast Internet access, but only the first time (later
CVS updates usually take no more than a few minutes).
It is probably a good idea to use current CVS gcc sources too, but
be careful - they are being broken and fixed all the time :-).
One good trick when using CVS sources is to build in a separate
directory (so nothing is written to the CVS tree), like this:
$ cd egcs
$ cvs -z9 up
$ mkdir ../build
$ cd ../build
$ ../egcs/configure --enable-languages=c --target=avr # --enable-checking
$ su -c "make install"
(it is probably safest to rm -rf the build directory each time
you do a new build - in theory, makefile dependencies should do
the right thing, but in practice it might fail sometimes).
The --enable-checking option is for the paranoid only (as of
yesterday CVS there was internal compiler error in libgcc2.c),
most people don't use it and live with these bugs...
The old stable gcc-core-2.95.2-avr-patch-1.1 could be made to
work with the new binutils by a simple 2-line change in avr.c
function asm_file_start() - this way you can have 2.95.2 (stable)
and 2.96 (CVS) installed at the same time, and choose one with
the avr-gcc -V option (the one installed last is the default).
> (As an aside, I have been using GNU C for AVR for several weeks now and
> ecstatic to have such a great development system! Thanks to everyone who
> has made this possible!)
Yes, it is great, but projects like this can never be said to be
really finished, there is always one more bug or optimization :-).
One thing still really missing is support for multiple address
spaces (program and data), so you can access constants in program
memory directly from C without these ugly macros. Not easy to
implement though (needs significant changes in gcc core sources,
not just in the AVR port), but potentially useful on some other
targets as well (many DSPs use the Harvard architecture too).