Compiling AVR Toolchain

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I reinstalled Ubuntu today, and thought, "hey, why not try to compile AVR-GCC"... I thought it would be fun, but it was a living nightmare.

Either way, I got it to the point where I had binutils, avr-libc and avr-gcc playing nicely. I learned a whole lot about the flexibility of gcc (you sure can do an awful lot of messing around before you even compile anything)

All of the following source packages were used in this installation:
gcc-4.4.3 (which also needed gmp-4.3.2, mpfr-2.4.2, and the m42 package)
avr-libc-1.6.8

I got it all compiled and installed into /usr/local/AVR, got my path all set up (which was rather annoying in Ubuntu), and decided to try and spin my first hex file.

And then the error came:

johnny@johnny-desktop:~/coding/avr1$ make

-------- begin --------
avr-gcc (GCC) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: blink.c
avr-gcc -c -mmcu=attiny84 -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./blink.lst  -std=gnu99 -MMD -MP -MF .dep/blink.o.d blink.c -o blink.o 
blink.c: In function 'main':
blink.c:38: warning: unused variable 'increaseSpeed'

Linking: blink.elf
avr-gcc -mmcu=attiny84 -I. -gdwarf-2 -DF_CPU=20000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=blink.o  -std=gnu99 -MMD -MP -MF .dep/blink.elf.d blink.o --output blink.elf -Wl,-Map=blink.map,--cref     -lm
/usr/local/AVR/lib/gcc/avr/4.4.3/../../../../avr/bin/ld: crttn84.o: No such file: No such file or directory
make: *** [blink.elf] Error 1

This is the first time I've ever compiled such large programs in linux, and I'm wondering if I did something wrong. To me it seems like some kind of definition file is missing.

AFTER I went through all of this I found the sticky here with a set of scripts, but it uses an older version of gcc. I'm pretty sure the rest of my installation went smoothly, so I'm wondering if anyone has seen this error, knows what it means, and how I might go about fixing it.

If it does turn out to be too much of a hassle, I may just settle for using the script, but I really enjoyed the process of compiling the toolchain myself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It can't find the C runtime start up file (crttn84.o). I believe when compiling programs like avr-gcc on linux you need to tell it were the library/header files will be located.

There probable also is a command line switch that would explicitly say were to look.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at bingo600's scripts for building the avr-gcc tool chain? It's in a sticky at the top of the listing for this forum.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like Johan says you should look at Bing600's sticky thread at the top of this forum. The difference between what you've built and what his scripts build is that the the latter applies about 40..50 code patches to the source (the same set that are applied to WinAVR). Without these you may miss features, miss device support and perhaps most importantly miss important AVR bug fixes.

BTW to take all the hassle out of things Bingo also builds the tree each time he modifies the scripts and makes a .deb from it and posts this to my website at www.wrightflyer.co.uk/avr-gcc/ - just download the latest and "dpkg -i package_name.deb" to install. Of course this misses out on all the "fun" of building it yourself.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Of course this misses out on all the "fun" of building it yourself.

Think of it this way: You get more time to drink caustic soda, pull your toenails out with pliers and perforating your eyeballs with rusty nails.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:
Of course this misses out on all the "fun" of building it yourself.

Think of it this way: You get more time to drink caustic soda, pull your toenails out with pliers and perforating your eyeballs with rusty nails.

I _DO_ enjoy a nice caustic soda :lol:

all right then. It's just a damn shame I went through all this trouble before noticing the sticky. Not a chance in hell I'll be patching any software myself. It's just sad that you have to go to such lengths to program AVRs in an open-source fashion.

Quote:
It can't find the C runtime start up file (crttn84.o). I believe when compiling programs like avr-gcc on linux you need to tell it were the library/header files will be located.

That doesn't make much sense to me. Aren't library and header files the kind of thing that have to change frequently? Why would they be involved in compiling a compiler?

I get the feeling these .o files have something to do with uC definitions because the code after "crt" is the mmcu of the uC I'm using.

---

Tried searching for "crttn84.o", got nothing.

*insert extreme disappointment*

Moral of the story: Let someone else figure it out. Just install the package, dumbass. :P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well just to give you an idea. Here's what the .map file says if I build for tiny84:

.text           0x00000000       0x44
 *(.vectors)
 .vectors       0x00000000       0x22 c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr25/crttn84.o
                0x00000000                __vectors
                0x00000000                __vector_default

Obviously the "front end" of that path is different on a Windows system but the latter part that is relative to gcc/avr/4.3.3 differs from your:

gcc/avr/4.4.3/../../../../avr/bin/ld: crttn84.o: No such file: No such file or directory 

It's looking for runtime libs in .../avr/bin when they are actually in .../avr/lib/...

I think this comes down to a ./configure type of problem. I think one of the ./configure options is to specify the location (maybe relative?) to the run time libs. Sounds like it needs to be specified and may have defaulted to something silly?

If you compare Bingo's GCC build script to the way you configured the package maybe something obvious will jump out?

Or just use Bingo's working solution and be done with it? ;-)

(another solution would be to "find" the crt file under /usr/local/avr and copy it to the place that the toolchain is looking to find it in - but this is a bit "kludgey")

(another option is that avr-ld almost certainly has some command line option that could be included in the LDFLAGS to direct it where to look for CRTs)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

crttn84 -> C Run-Time for ATtiny84, methinks. (On the "crt" part I am almost dead certain.)

So that file is the part-specific part of the run-time support lib.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any idea how soon the 4.4 variant of GCC will make it to avr-gcc in the build script (probably not until it makes it to WinAvr, I'm guessing Bingo is riding Jorg's coat tails on this one)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm guessing Bingo is riding Jorg's coat tails on this one

The gating factor is when Joerg posts the patches to Free BSD where Bingo can collect them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
That doesn't make much sense to me. Aren't library and header files the kind of thing that have to change frequently? Why would they be involved in compiling a compiler?

The compiler needs a default search path. So even when/if the library's and headers change the compiler will have a place to start searching. when compiling the program it needs the locations of the files and not necessarily the actual files.
Quote:
I get the feeling these .o files have something to do with uC definitions because the code after "crt" is the mmcu of the uC I'm using.
The CRT files are uC specific. They, among other things, initialize global/static C variables.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

They, among other things, initialize global/static C variables.

But that part is generic - the per CPU or per architecture nature of the CRTs basically comes down to the different vector tables and setting of SP to RAMEND.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It could be , that the avr25 isn't a known architecture in an unpatched 4.4.x. , or binutils for that matter.

/Bingo