Avr-libc 2.0 not compatible with gcc 4.4-

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

I hadn't seen this noted anywhere, not that I know where to look, but it wasn't obvious: the  'deprecated' attribute used in avr-libc 2.0 is not compatible with the older  'deprecated' attribute.  You'd think that the gcc folks would have just deprecated it but.. whatever.

 

The end result is, you can't change to avr-lic 2.0, and re-build old projects, using the old compiler, using old code.

 

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

The issues of AVR-LibC are very closely tied to the compiler. For example just because there's an avr/include/avr/iotn1634.h in the AVR-LibC stuff does not necessarily mean the compiler supports -mmcu=attiny1634 so, yes, you need to use the version of AVR-LibC that was intended to be used with a specific issue of the copmpiler. For an ancient avr-gcc 4.4.x I guess that means probably LibC 1.8 or perhaps even 1.7

 

Sure you can "cherry pick". Like you might want time.h from 2.0 but then you face things like the fact that EEPROM support was changed RADICALLY around about 4.6. It used to be the case that for any of the 17 (could have been less back then) AVR architectures there was a single libc.a that contained things like eerd_m16.o for doing EEPROM reads on the atmega16 but these days there is no EEPROM support in libc.a and instead there is a libm16.o that contains the EEPROM support for mega16.

 

Just out of interest WHY would you want to do this? If you are upgrading to Libc 2.0 why not upgrade to a compiler that matches it such as 4.8, 4.9 or even one of the issues of 5.x ?

 

Atmel's current issue of avr-gcc for Windows is a 4.9.2 variant. That's what the vast majority of people (AS7 users) will be using alongside LibC 2.0 right now.

 

If you want to get "ahead of the curve" go here:

 

http://gnutoolchains.com/download/

 

That gives you a shiny new 5.3 together with LibC 2.0. HOWEVER this is from the generic build tree, not the Atmel one, so a lot of the support for new AVRs that Atmel haven't quite finished pushing back to generic will not be covered. But if you are building code for devices that were supported by 4.4 then this should have all those (and more!).