Actually I had forgotten about Cliff's packages....
Thanks for the link. I see he DOES have BOTH the x86 and AMD64 versions. What I DON'T know is if he built them under pure Debian or a 'buntu flavor.

The only possible problem might be compatibility between Debian and Ubuntu. *SOME* Debian packages are NOT compatible with Ubuntu (and visa versa) even though they are BOTH .deb in structure. I'm running Linux Mint which uses the Ubuntu repository for most packages. Naturally the mix of libraries is part of the issue, so when unsure it's better to just build it from source on the system where it will be used. (No, I'm NOT a 'BSD fan).

I think I found a bug in the build script. In the buildavr.log I found the following:

cp: cannot stat `gmp-6.0.0a/*': No such file or directory

This is from the following line in the build script:

cp -rfp ${gmpbase}/* ${gccbase}/gmp

The problem is the script assumes the basename of the gmp archive (gmp-6.0.0a) is the name of the directory created when the archive is extracted. However the directory name in gmp-6.0.0a.tar.bz2 is gmp-6.0.0 (no 'a' suffix).

I manually copied the gmp source files and re-ran the build script.

I have no special talents. I am only passionately curious. - Albert Einstein

That seems like a sensible explanation to the error , and yes the immediate cure would be to manyally copy the gmp source files , or to extract the gmp sources , rename the directory to the "a" name , and repack it.

I'm probably not going to update the buildscript , as it's only a few capable people using it today , and i expect that they can do the same reasoning as you.

For latest Atmel device support you are (currently) better off sticking to Atmel builds. So while 4.9 may look enticing I'd just take Atmel's 4.8.1 and use that for the time being. Atmel haven't released a toolchain for a while so I rather suspect they are waiting for the 4.9 dust to settle and we may see one shortly anyway.

They are working (see the check in history at the AVR-LibC repo and all the activity from Atmel employees) to push their private changes for added device support back upstream so the generic build will mirror their own local build at which point it won't be necessary to have an Atmel one at all - but that's still work in progress and until then the Atmel builds remain the best option - especially for "none mainstream" devices like the one you want to use.

I sort of assumed the posting on the website might be part of the auto-build process. Perhaps that last step simply does not work for some reason or maybe it was that the build of the AMD64 version did fail for some reason?

The avr-gcc etc are in ./bin and the base of the includes are at ../avr/include/ from there - that would be the directory with stdio.h and so on. Then all the AVr specific stuff is in an ./avr/ from there (that is ../avr/include/avr/ from the ./bin/) which is why io.h is referred to as <avr/io.h> in AVR programs.

To be honest I don't know why you don't just get the .tar.gz from atmel.com and unpack it (though I understand the current issue with no linux64 build).

Had to give up on AVR Linux, the tools are 4.81 and the Eclipse AVR add in does not pick up the arv/io.h file so it will not allow selection of a MCU. I did a git and found where he was parsing the directories but couldn't figure out why it was failing.

Atmel Studio 6.2 (AS) on Windows 10 was working until they installed the latest build, it killed all the USB drivers, didn't like them, they were not branded by Microsoft so they killed them. Several application from the 'Store' died too so Atmel is not alone.

I restored a snap-shot of my Windows 7 workstation system before I installed AS and installed AS again, after it installed the first time I ran it AF told me it had an update, 100mb or so later it was install and now AS on Windows 7 x64 is working.

Here is the deal: gcc 4.80 ~ 4.82 are known to be faulty, the current compiler for AVR8/32 is gcc 4.81 for ARM 4.84 so is it safe to use 4.81 on an AVR8 device?

Yes but note that ALL compilers have bugs. GCC is pretty good with its release schedule so some get fixed quite often but 4.8.1 (and 4.9.2) will have bugs. You just have to hope (as with all compilers) you don't hit one that affects what you happen to be trying to do at the time. Having said that I consider 4.8.1 from Atmel's build to be pretty stable.

(ah "masm"! - those were the days! having used the CP/M assembler before it the thing seemed so "grown up" when I first used it!)

Well, this building script seems to work good on a RPi : it takes hours, but generates avr libraries. However, there is a small flaw: usually, prefix is used to denote the directory where the results (compiler, gas, libraries, doc) will go : it may be in a small disk; the place where one builds (huge amount of *.o, ...) can be in a separate disk (it is cleaned after building, but it eats disk space), at least in a distinct directory. This does not matter with usual disks, even USB keys -one can install x86 - GNUlinux on a USB stick now-. But RPi "disk" is a SD card : it is expensive (twice as USB sticks), and maybe wear out : seems a bad idea not to separate the building directory trees from the installed one.

Iknew one can mount external usb disks (rotating ones, with a low price per GB): this was the way I got avr-gcc built,, with salvaged laptop 250GB disk and an adapter. One can even, atleast theoretically, boot from it -only the fat part of the RPi SD is mandatory -; but , if new , this makes price double ... Main issue is that one cannot, with this script, build on the hard disk and move the result into the SD, "prefix" being used to denote the downloaded sources, the temporary directories to untar and compile (I know one can make mount points, but it is not what comes into mind) and the result which should go into the SD in a classical configuration....

Well, thanks Chapman for the information. I knew that one can use an external -USB- rotating disk (price per GB is very low) -one can even boot from it, only the FAT part of the SD is mandatory- but it is not a standard configuration, doubles the price and makes connectivity complicated . I got avr-gcc compiled on an external -250GB, in 3 parts- USB HD but I cannot -maybe a copy works, if generated compilers /libraries are directory-tree independant...- put it into the SD as directories to download sources , directories to untar and compile and result directories are in the same tree denoted by "prefix" (I did not try to fix it with mount points during buils, as it is not standard).