Guyzz i have succeded in building avr-gcc-4.3.4 w. avr-libc-1.6.8 , and JÃ¶rg's latest patches on my Ununtu 10.04

Quote:

I'm only testing on the latest Ubuntu LTS.
All other version & distro's , are not guaranteed to work/compile. I'll try to help out , and so will the forum i'm sure. But don't demand support if it doesn't work , just ask nicely in the forum

I am enclosing the scripts i use (credits of A. Erasmus) , if they could be of any use

The steps are these:

Read Readme.txt
Then install the packages listed in pre-reqs.txt.

Note !!
Don't try to call the scripts from another directory location , always execute from same directory where the scripts are located.
The current scripts uses recursive deletes , that could erase the harddisk if the above isn't honored.

Then....

1: Make sure you are root (blushing) , or use sudo
2: Make a working directory , where you extract the files from the archive.
3: If desired edit the buildavr-no-insight.sh file , to change the prefix .. default is : prefix=/usr/local/avr
4: Make sure that the prefix dir is empty or nonexisting
5: Run : chmod +x *.sh
6: Run : ./getfiles.sh
7: Run : ./get-patches.sh
8: Run : ./buildavr-gdb.sh
9: Run: ./buildavr-toolchain.sh

You just answer yes to the existing directory question in step 9.

When building is done , you might want to free around 500MB of diskspace by removing the sources and binaries used to make avr-gcc.
To do so Run: ./buildavr-cleanup.sh

Note this little script expects the "build prefix" to be /usr/local/avr/

Edit:2
I have an avr user on my Linux-box for doing avr development , i have added this to my .bash_profile in my /home/avr directory , it sets up the path to avr-gcc.

The script builds avr-gcc-4.3.4 w. binutils2.20 and then avr-libc-1.6.8
The script now also automaticly builds avarice-2.10 and avrdude-5.9 , as per request of JÃ¶rg.

Note : gcc-4.3.x uses the GMP & MPFR libs , in order to function. So make sure to install the packets mentioned pre-reqs.txt

avr-insight is upgraded to ver 6.8 witch builds ok on 64-bit machines , and it has its own buildscript (buildinsight.sh) , as it takes ages to build.

Use: tar xvzf to extract it if it's a .tgz file, or unzip if it's a zipfile.

Just ansver yes if any of the scripts says that /usr/local/avr exists (ie. when building insight after gcc or the other way around.

But always delete /usr/local/avr before you are making a total/new rebuild.

Quote:

Updated the scriptfiles to build binutils and insight without the -Werror flag. This was caused by GCC 4.3.x (on Ubuntu 8.10) being unable to build the targets. And was due to a lot of new warnings being enabled by default.

Quote:

@20-jun-2009
Upgraded the "old" script building avr-gcc-4.2.2 to build avr-gcc-4.2.4 ... "JÃ¶rg did all the patches".
4.2.2 could produce more compact code in some cases.

Quote:

@14-jul-2009
Upgraded the script to build avr-libc-1.6.7 and avrdude-5.8 , no changes to avr-gcc.
As usual "JÃ¶rg & the others" did all the hard work.

Quote:

@12-aug-2009
Upgraded the avr-gcc-4.2.4 script to build avr-libc-1.6.7 and avrdude-5.8.
Also applied a "Hotfix patch" to binutils , to avoid a relocation error in the AVR25 architecture (tiny85 etc).Everybody is urged to rebuild their toolchain

@16-Jan-2010
Updated the avr-gcc-4.3.3 script , to build avrdude-5.9
Removed the two "interrim avrdude patches" , as 5.9 should fix that.
All other remains unchanged.
The script still includes the "AVR25 relocation fix" patch , and the avarice patch

> Is there an easy way to drop the -Werror using the script? It fails
> on a ubuntu 6.10 ...

"Is there a way to get rid off these seat belts? They are always in
my way."

The correct solution is not to remove the -Werror but to remove the
warning triggering your problem. Not having Ubuntu Linux, and you not
quoting it, I can only guess, but I assume it's:

wrcoff.c: In function 'coff_start_struct_type':
wrcoff.c:2277: warning: value computed is not used

FreeBSD's CVS version recently also switched to GCC 4.x, and thus also
stumbled across that one.

I have just updated the COFF patch for this in my FreeBSD port. The
solution was much simpler than your attempt to get rid of the -Werror:
a "(void)" cast had to be placed before a function call that returned
a value that was not used. (Upon thinking of it, I'm asking myself
whether ignoring the return value is actually the right thing to do,
but at least, it's been that way all the time, and I don't really see
the Big Picture of all this anymore after that many years.)

I also updated the ATmega256x patch in binutils to get rid of that
annoying "operation is dangerous with linker stubs" warning that was
triggered by large C switch() statements. In a discussion with Björn
Haase, we agreed that this was a regression (it wasn't really
dangerous in the switch() situation anyway), and also not all that
useful as Björn initially believed, as there are many more other ways
to shoot into your feet with the linker stubs which cannot be warned
about anyway. So that warning is gone now. (This matches the patch
Eric is using for his most recent WinAVR.)

I seem to recall having read that once upon a time the /usr/local/avr prefix was chosen so that it would be a simple matter of blowing away the entire directory to get rid of *everything* AVR-related from the filesystem without worrying about:
1) Accidentally removing anything non-AVR-related in the same operation
2) Accidentally losing track of some AVR components and orphaning them

I'm sure there are better ways to accomplish both of these tasks nowadays though.

> I'm sure there are better ways to accomplish both
> of these tasks nowadays though.

Only if you are carefully tracking the files you did install.
That's where the package management systems of the various Unix
systems come into the game. If you are installing something
outside of these package managers, you have to track that
yourself.

Each of the tools should also come with a Makefile target
"make uninstall", but I wouldn't hold my breath to see whether
they are really removing everything (including perhaps empty
directories they once created): these targets probably belong
to the lesser tested features even if they come "for free"
along with autoconf/automake.

I change my PC and now I installed Ubuntu 7.04. The script work perfectly with my old PC and Mandrake 2005 (not with 2007).

AVR-GCC package download don't work on tiny45. Then I want compile this version and patches (tiny45) but ./configure indicate : "C compiler cannot create executables". I try different options but there is always this error :oops:.

IIRC Ubuntu doesn't come with a native C compiler as part of the standard installation. You need to install GCC separately (using apt-get or Synaptic) before you can use it with Bingo's script to build AVR-GCC.

I hope this link will be useful for someone. Using that how-to I have installed avr-gcc on my Linux Suse 10.
Link: http://www.linuxjournal.com/arti...
I have compiled binutils, gcc and avr libc. When I was compiling simulavr I had been given a mistake.

It seems to me that at some point someone in this community should realize that the preeminent source of stable code in this chan is maintained in the FreeBSD ports collection.

I have finally gotten around to working on a generalized 'portscrape' method. This will actually build the toolchain on SLES 10 and should keep up with whatever revision is blessed. (This seems to need some tweeking to work on OSX's bash.)

That would be my point with the exception of the patches that you discussed in the osx-avr thread.

Taking this one step further.

The /usr/ports/devel/avr-.* directories contain not only the current patches for .*x systems, but also the source locations, the environment and compiler flags to compile them. Which is why I suggested that a script would be better off extracting this data from the definitive source than rewriting a fresh script every time. The script above was an attempt to hack out a quick proof of concept. It isn't pretty but it works.

There is a good deal of other material in each ports Makefile including descriptions, dependencies, versions and file manifests which could be scripted into depots (hpux), packages(solaris), PackageMaker files(osx), .dpkg's (debian) or rpms.

pushing out from there
a) This could be rewritten in a more robust shell such as perl and generalized to create a framework from scraping the data into patched source trees or various package formats. This might serve to rapidly decrease the delay between your releases and releases by and for the rest of us.

b) More investigation on the OSX side could be done in carrying on the early "port the ports" efforts which were made when darwin first came out. If you pull the source manually into distfiles you can actually run bsdmake from an unmodified ports tree and get the more difficult work done (patch,configure,compile). It makes me wonder what a body could do with a few choice modifications to the /usr/ports/Mk directory.

Hmm I think I used the script before a year+ ago, but now it "evolved" into something else.

Is there still a script that does the build without any frills ? I don't want Tk, I don't want tex, I don't want a graphical debugger (!) heck I don't want a debugger even ! And I certainly don't want that before I have a binutils/gcc toolchain working.

I have avr-gcc and avr-libc installed on my opensuse system. ive tested that im able to compile a very basic program (making a led light up when a button is pressed). is there any reason i should ditch my current setup and install things this way?
and btw, totally new to this =)

Note to any other newbies like me out there... if it fails after running the getfiles and patches scripts asking for a lib from binutils be sure to read the pre-reqs file and install the necessary packages.

I would like to thank everyone who has contributed to this effort. The results are wonderful. I had spent 3 days by hand attempting to do what your scripts did in several hours. It looks like everything has compiled and installed properly. I am able to compile and burn images to a 3290p device without issue.

The last remaining piece I have is an issue with avr-insight. It seems to have an issue with tk.tcl not being installed properly. I checked the directories it was searching and found the files there, but no such luck. Anyone else have an issue with tk.tcl?

The last remaining piece I have is an issue with avr-insight. It seems to have an issue with tk.tcl not being installed properly. I checked the directories it was searching and found the files there, but no such luck. Anyone else have an issue with tk.tcl?

I had exactly the same problem. As ddd rather than insight is my poison of choice anyway I just did an apt-get on that and used it as the front end to avr-gdb

Ah, that may explain it. I hate all this protection nonsense in Linux (now creeping into Windows too) so just as I always run as Administrator in Windows I always run as root in Linux. Having said that I actually installed and built the toolchain as root so I should be the "login user" for it anyway.

Bingo, perhaps you should note that to download (and even see!) the scripts, you have to be registered and logged in. I always come to get the scripts when I am logged out and look aimlessly for the scripts for about a minute before realising I have to log in!

Hi,
Thanks for this useful thread.
I got an error when compiling with ./buildavr-no-insight.sh on my system: the error is due to my version of gcc installed on my PC, version 4.4.1. I got an error with "const char *" instead of "char *" which stopped the compilation.

To solve it, I added a 'sed' instruction to /buildavr-no-insight.sh before the avarice compilation:

Hi,
Thanks for this useful thread.
I got an error when compiling with ./buildavr-no-insight.sh on my system: the error is due to my version of gcc installed on my PC, version 4.4.1. I got an error with "const char *" instead of "char *" which stopped the compilation.

To solve it, I added a 'sed' instruction to /buildavr-no-insight.sh before the avarice compilation:

Hi, I was wondering how this installer script differs from the WinAVR package. I see that the newest "stable" WinAVR release consists of GCC 4.3.2 + avr-libc 1.6.4 + a lot of patches. Bingo's script uses more recent sources but with less patches. Which of these would be the more bug-free package?

WinAVR has a pretty large user base, so I guess their packages get quite a lot of testing. Also, it would be nice (sometimes even compulsory) to get the exactly similar avr hex files from both Windows and Linux development environments.

So, my question is, would it be a good idea to also provide an installer script that installs a package exactly like the WinAVR but for Linux? Or do you think that Bingo's script is in all aspects better, and instead we should use this script also in windows?

Hi, I was wondering how this installer script differs from the WinAVR package. I see that the newest "stable" WinAVR release consists of GCC 4.3.2 + avr-libc 1.6.4 + a lot of patches. Bingo's script uses more recent sources but with less patches. Which of these would be the more bug-free package?

WinAVR has a pretty large user base, so I guess their packages get quite a lot of testing. Also, it would be nice (sometimes even compulsory) to get the exactly similar avr hex files from both Windows and Linux development environments.

So, my question is, would it be a good idea to also provide an installer script that installs a package exactly like the WinAVR but for Linux? Or do you think that Bingo's script is in all aspects better, and instead we should use this script also in windows?

The script & patches i use is based on the FreeBSD repository (JÃ¶rg maintains it).

If you want to build a toolchain , that uses WinAVR patches (Eric.W/EW maintains it) , have a look here.

EDIT:
In file get-pathes.sh i saw the note aboute skipping wget for this patch since its a part of atm package. However, I need to research more to understand what that means..

EDIT:
I did a super guess and assumed it refferes to patch-avr25-wrap at the freebsd server. I installed this and renamed it to binutils-patch-avr25-wraparound-reloc.diff and restarted build. That seems to fix the problem. Hope it was the correct patch though, from Joerg... :roll:

Please, for the love of all that is holy, at the top of the very first post, in all caps, add the line:

YOU MUST LOG IN TO DOWNLOAD THE SCRIPTS

I banged my head against the wall for half an hour trying to find the gorram scripts everyone kept talking about and couldn't find them anywhere. Only after I gave up and decided to create a forum account to tell you all what nasty horrible evil people you all were did I actually see the download links for the scripts. If you're not logged in you don't see them. It's incredibly frustrating for a noob. Please, save other people from this frustration.

Compiling the demo for Appnote AVR1300 (ATXmega128A1) the generated code for the ISR entry sequence has a bug.
This is only when compiled on Linux by the compiler generated by your last build script. The code generated by WinAVR 20100110 does not have this error.

I cant get a working avr-libc from this plus the patches from the latest winavr and now have a toolchain that claims but it has the target but the freshly rebuilt libc cant link the crtmxxx files. Jeorge just send the linux folk with this problem to your script.

Or were you simply saying that dpkg barfs because of an architecture flag in the .deb metadata? If so then from "man dpkg" I note:

Quote:

--force-things | --no-force-things | --refuse-things

Force or refuse (no-force and refuse mean the same thing)
to do some things. things is a comma separated list of
things specified below. --force-help displays a message
describing them. Things marked with (*) are forced by
default.

Warning: These options are mostly intended to be used by
experts only. Using them without fully understanding
their effects may break your whole system.

My reading of the man page is that the words literally are "--force-things architecture" not that either "things" or "architecture" is a placeholder for you to fill in with some value. All you are saying is that "usually you do an architecture check, this time skip it"

My reading of the man page is that the words literally are "--force-things architecture" not that either "things" or "architecture" is a placeholder for you to fill in with some value. All you are saying is that "usually you do an architecture check, this time skip it"

bumping the insightver from 6.8 to 6.8-1 in package-versions fixes the tk.tcl error mentioned earlier in the thread. Both patches still apply. It now runs fine in ubuntu 9.10.
from the insight homepage:

Quote:

Updated Insight 6.8-1 available
Insight 6.8 has been available for some time, and the current release tarball has issues with newer versions of X11. As a result, I am making available a patched Inisght 6.8-1 release which should fix all outstanding issues with X11.

bumping the insightver from 6.8 to 6.8-1 in package-versions fixes the tk.tcl error mentioned earlier in the thread. Both patches still apply. It now runs fine in ubuntu 9.10.
from the insight homepage:

Quote:

Updated Insight 6.8-1 available
Insight 6.8 has been available for some time, and the current release tarball has issues with newer versions of X11. As a result, I am making available a patched Inisght 6.8-1 release which should fix all outstanding issues with X11.

Hi all,
however I used winavr on windows, I'm a novice in using avr-gcc on Linux. Winavr gave me the comfort to forget Makefile and now I'm in trouble.
I suppose I got the message below due to the wrong setting of makefile:

To find out which files "belong" to a specific .deb and will be removed if you either "apt-get remove" or "dpkg -r" it then use:
Code:
dpkg -L

Unfortunately it does not help. It seems that avr toolchain was installed from source and was not a .deb package. I've tryed to setup a toolchain earlier and now I am probably hindered due to the rest of that unsuccesful experiment. I have no idea how to remove a program installed from source. So I guess I should
- remove Bingo's package
- then manually clean up /usr/bin directory from all avr-related programs
- and then re-install Bingo's package.
Any better idea?

. I have no idea how to remove a program installed from source. So I guess I should
- remove Bingo's package
- then manually clean up /usr/bin directory from all avr-related programs
- and then re-install Bingo's package.
Any better idea?

Technically you could make sure that /usr/local/avr/bin is on your path before the "other" place/package is.

But i'd clean out the "other" place , just to be sure.

There is no need for uninstalling the .deb
The deb only install files in /usr/local/avr , and as long as you don't touch anything there , you can leave it installed.

There is no need for uninstalling the .deb
The deb only install files in /usr/local/avr , and as long as you don't touch anything there , you can leave it installed

Thanks for all the answers.
The key of the mystery was the path. I've supposed the /usr/local/avr/bin path will be added to my path by the script - and even worse, there was that forgotten, partly aborted version of avr toolchain.
Now as I set the path, everything is right. Thanks for the script, Bingo!
Istvan

Hi,
I'm using avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb package and I'm trying to program an avr ATXMega256A3. Compiling with avr-gcc and flashing with avrdude works great. I use an MKII Jtag ICE to upload the application on the flash and I'm trying on chip debugging. It looks like on chip debugging is working right as when I hit CTRL+C it stops running and gdb tells me the instruction where the application stopped.
However I can't watch / display variables nor set/delete breakpoints.
Xmega256A3 data is store in SRAM (0x802000 0x805FFF). when I try to print a variable, and watch avarice debug, I see something like this:

As you can see from the debug information, gdb asks for location (0x800000 + 1) and does not account for the data offset NOR for the fact that data is stored on the ATXMega starting from the higher addresses (0x805FFF) up to the lower ones).

I wonder if it's gdb or avarice responsibility to account for these offsets...

I'd really appreciate your help guys...

Thankx in advance
I'm be waiting for any comment help hint or scolding me..

FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.

For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.

FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.

For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.

The scripts use a dangerous approach of assuming various directory creation and navigation commands work and then executing "rm -fr *" without ensuring that the current directory is what it should be. I had to spend a good chunk of last Sunday restoring from backup after one of the scripts wiped out a large part of my home directory.

Following the scripts and attempting to replicate the build process by hand yields a toolchain that works for tiny26 and mega32 projects, but can not find C runtime files for the xmega32A4:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: crtx32a4.o: No such file: No such file or directory

This file does exist, it's in /Users/cjh/avr/avr/lib/avrxmega2/crtx32a4.o (prefix is $HOME/avr/). Moving it into the project directory yields different errors with libmath and libc:

And similar for the libraries, but long lists of entries of the same format and architecture "avr".

I'm using Mac OS X 10.6.5. The major differences from the scripts are that I'm using avr-libc-1.7.0, more recent versions of GMP and MPFR, and removing an instance of tree-inline.o from the GCC makefiles to fix a duplicate symbols problem. (bug in Snow Leopard's linker...won't ignore duplicate symbols from static libraries)

That is the buildscript I used, but it was get-patches.sh that blew away part of my home directory. There's several times that it does mkdir's and cd's without checking for failure, blindly does "cd ..", and it simply experienced a couple failures and climbed up into my home directory before doing another "rm-fr *".

It would be much better to always specify full absolute paths, especially in the rm command. This alone would have prevented the issue, since it would have been trying to rm a nonexistent directory...it would not matter if it were in the wrong directory following a failure. I would also suggest simplifying it to put everything in a fully specified build directory rather than constantly creating and deleting this and that...it would be simpler, clearer, and less fragile.

As for the readme, I strongly suggest reorganizing it. There's no clear starting point for figuring out how to use the scripts, the quoted portion at first glance appearing to be an old portion of the revision history.

Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?

It's good you've never had them run amok, because they would have done a lot more damage if you were blindly following those directions. Running the scripts with the root or sudo privileges needed for an install to /usr/local would not have improved matters...it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there. As it was, I noticed it was misbehaving when it started hitting files it didn't have the permissions needed to delete.

And yes, aside from limiting the potential damage from misbehaving scripts, building a standalone toolchain makes it trivially easy to switch between different versions of a toolchain, and keeps all the stuff related to that toolchain in one place. I didn't install to /usr/local because I didn't want it there.

It's clear that there's a major issue with the scripts' assumptions that directory creation and navigation will always succeed, coupled with running a dangerous command without any sanity checks. That you've never had trouble does not change the fact that failures can lead to it blindly deleting everything in higher level directories. Depending on the choice of download locations and how closely the directions are followed, it can delete nearly everything on the hard drive, OS included. Is your response to this really "it always worked for me" followed by questioning my choice of install locations?

it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there

Wouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.

Well good for you! Can you at least admit that this might be something of an issue for other people?

It's simple. Potentially crawling up your directory tree and deleting everything in sight without warning is not desired behavior, okay?

Bingo600 wrote:

Well it's always nice with some feedback , even though you are the first i have heard about that has lost control.

And people has been using the scripts for four years now.
With the above mentioned readme et all.

I hope Ruud's script lives up to your expectations.

Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.

Maybe i'll add a check for that.

:shock:

Look. Running the scripts as instructed is potentially equivalent to typing "sudo rm -rf *" in any containing directory, up to and including the root directory of the filesystem. This is a major issue that needs fixing, the scripts in their current state are brittle and fail catastrophically. That you haven't had reports of issues up to now is pure luck. You have now had such a report, and a clear description of what the problem is and why.

There is no reason to clear out unneeded files by attempting to cd to a location and then deleting everything in the current working directory. Simply working out what directory the items to be deleted should be in and passing that to rm will avoid the issue...if the directory doesn't exist, the script won't fail by crawling up the directory tree deleting everything in its path. This doesn't take a huge amount of effort to implement, and doesn't make things harder to maintain or follow...if anything, it makes it clearer what the scripts are doing and easier to ensure that they do only what you want.

The 2 parameters are a remainder from the original arm-gcc-cross-compiler building script. However both of them are correct and do not affect in a negative way the building of the tools (feel free to try).

The package for ubuntu, available here:http://www.wrightflyer.co.uk/avr...
is broken as I have mentioned. It did not include the patch for delay.h.in in the avr-libc-1.7.0. One more reason why to have a building script functional that can be easily modified (I find more easy to modify my script than yours, no offence).

Why GCC-4.5.2? Well, I believe is better to go with the latest version, since they generally bring improvements. However, after a little Google (one of my friends suggested I need some practice on this...):
- from http://gcc.gnu.org/gcc-4.5/chang...
- new link-time-optimizer (sounds nice from description)
- automatic parallelisation pass
- optimising exception handling code (probably doesn't apply to our AVR targets, but still nice)
- just C related:
- -Wenum-compare option to warn about different enum types
- Added support for these new AVR devices:
ATmega8U2
ATmega16U2
ATmega32U2
- it is now possible to extend the compiler without having to modify its source code
- from http://gcc.gnu.org/ml/gcc-announ...
- improved loop optimization infrastructure
- GCC 4.5.0 also features improvements for a wide variety of specific
architectures, including support for recent CPUs using the ARM, AVR...
- many more ... (please read the links above).

The wisdom of the libc/avr-gcc maintainers is almost always the better place to start. It takes for fracking ever for anything to actually get released into gcc. And new processors are going to be unstable for a while. The patches that bingo uses which are from the toolchain maintainers mouths are based on the latest and most stable versions for this processor.

I suppose it was EW's hints on the avr-gcc list what brought you on track.

Congratulations in writing a very nice buildscript.

It still amazes me though :
That you chose to ignore the warnings in the last posts about using the unpatched upstream avr-gcc.
Instead of the proven 4.3.4 with the current maintainer patches applied.
These patches are created by Eric Weddington (WinAVR) , who adviced you on the "list". And JÃ¶rg Wunsch (avr-libc & FreeBSD port of avr-gcc).

And i sincerely hope your students won't be bitten , as these patches most likely haven't gone into the version of GCC that you are using.

@Omar
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Btw: The reason i haven't updated the .deb packages with the new delay.h is that i follow the FreeBSD source like 99.9% , and JÃ¶rg hasn't released avr-libc-1.7.1 yet.

There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.

I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.

There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.

I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.

I don't have any examples , but i'm quite sure that it was Eric (EW) mentioning this on one of the mailinglists. As an answer to why patches wasn't moved upstream.

Is there a _single_ location available that at least links to all the files necessary to get up-to-date mcus working?

I must have spent have a day compiling (using the script and the manual on the avr-libc site) only to find out that e.g. my newly acquired ATtiny4313 is not supported by the compiled avr-gcc version I got. Woohooo! Happy happy joy joy.

I don't mind the compiling part too much (well it basically sucks, but it is still tolerable), but finding all the patches... good god! :x

How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.

How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.

I have the impression that winavr is sometime more a fork than a port and that quite few things don't make it back into the gcc. maybe just due to the lack of motivation my Atmel to provide the work to make it happen. After all in winavr it works and other development platforms than Windows don't exist / are negligible (See the wonderful new Studio 5 based on Microsoft Visual Studio).

I think I'll have to agree with the fork vs. port part, but Atmel could at least have had the decency to use QT instead of the horrid MS stuff. It looks more and more like MS-word. Does it have ribbons as well?

And why do I need to register just for downloading a free-of-charge IDE? Is that strictly legal, having to register to get access to software that is - at least partially - licensed under the GPL?

Sheesh. Isn't it enough that I buy some of their chips already. Knowing who I am and what I do won't miraculously octuplicate their sales and blow away their competitors...

I installed AVR Studio 5 yesterday - it supports Tiny4313. When it was pointed out to Atmel that they'd shot themselves in the foot by delivering (again) a Windows only package the retort was that while the IDE may be tied to Windows the toolchain was "cross platform". Now I don't know how they can make that claim without providing Linux binaries x386 for the avr-* tools in the toolchain - but maybe they are lurking in there (I haven't looked)?

It was Dean, who said that the underlying stuff is cross-platform and only the IDE is Windows specific. This might be correct in theory and marketing speak (gcc is cross-platform), but in practice this is clearly false. After I pointed out to him that an 500MB exe file is not cross-platform did not venture any further comment.

I respect Dean and suspect he was carried away with his remark. I don't think he works in the Studio team, so he might just defend them without knowing all the details first hand.

I don't need a single click 500MB installer for linux, the script provided here is sufficient for most of us Linux guys. But it looks like we are deliberately ignored.

It basically does all the work. Only currently (well yesterday) it unfortunately does not produce a version of avr-gcc that supports the tiny4313.

The best I could do myself was to apply a patch to avr-devices.c to make the compiler aware of that chip. But later the linker barfed about a missing .o file - which existed.

If atmel is so stuck-up to ignore everything beside windows, they can't be helped and will pay the price once MS faces its inevitable end. I just love companies taking advantage of open source software and give back nowt.

I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.

Maybe it's time that someone shoves that message up the a*ses of the bean counters in management.