Sì, la patch vale solo per utenti di Arduino perché altrimenti dalla toolchain ci si aspetta quel file.
Sul fatto che non si verifichi quel bug non so. Stando a quanto aveva detto anche astro, ci voleva l'include di 2 librerie per far funzionare le funzioni temporali ma a me lavorano senza intoppi anche senza senza. Ho preso lo sketch Blink, che usa il delay, l'ho compilato senza errori e poi l'ho uploadato sulla mia UNO, e gira senza problemi, lampeggiando come deve.
Sono emozionato... in Arch è arrivata la toolchain Avr con avr-gcc 4.7.0 nel repo del ramo stabile....
Ora aggiorno e vediamo un po'....
EDIT:
come non detto, l'emozione gioca brutti scherzi. E' la toolchain Gnu, non Avr, quindi gcc/binutils/glibc. Però è un buon segno, se è arrivato questo "blocco", il blocco Avr penso che sia di lì a venire, ormai. Attendo con impazienza 
Da qualche giorno è arrivata nei repo Arch la toolchain Avr aggiornata alla versione 4.7 di avr-gcc. Spinto dalla curiosità ho disinstallato la precedente toolchain Atmel e messa questa.
Errori:
#include <util/delay.h>
unknown name type: prog_uint8_t
questo errore compare su alcuni core (tipo il Tiny) che non hanno la definizione del tipo per la gestione con PROGMEM dell'unsigned char. Basta aprire il file pins_arduino.h contenuto in hardware/xxxx/core/xxxx (sostituire ad xxxx il core interessato, es.: tiny o 1284 o quel che è) e cambiare intorno alle righe 60-70 tutte le occorrenze di prog_uint8_t con PROGMEM uint8_t
errore bastardo! error: attempt to use poisoned "SIG_USART1_RECV"
Questo errore viene fuori praticamente con tutti i core riguardanti i chip che hanno più di una seriale. Ciò è dovuto al fatto che in avr-libc 1.8 è stata inserita una lista di definizioni deprecate, che vengono messe "alla gogna" dal compilatore nel caso il flag AVR_LIBC_DEPRECATED_ENABLE_ (come in avr-libc 1.8) risulti attivo.
Questa lista di definizioni deprecate comprende anche tutti i vettori delle seriali definiti con SIG_USARTx_RCV che, nella nuova versione, sono invece definiti con USARTx_RX_vect
Spippolando su internet ho trovato che un fix temporaneo è quello di editare il file HardwareSerial.cpp del core in uso e modificare le occorrenze così:
//#if defined(SIG_USART1_RECV)
#if defined(USART1_RX_vect)
(maggiori info qui)
Continuo il lavoro....
La cosa è un po' "pacco", nel senso che ho dovuto metter mano a tutti i file HardwareSerial.cpp e togliere tutte le occorrenze incriminate perché un semplice test #if defined() dava comunque l'errore visto che la definizione "avvelenata" non può essere in alcun modo toccata. La cosa positiva è che i vari core già erano predisposti perché c'erano nelle librerie i test per entrambe le definizioni.
Attualmente sembra che tutto funzioni. Adesso vorrei fare una prova con il famigerato bug dei 64kB. Ora ricerco lo sketch di astrobeed e lo compilo...
leo72:
Attualmente sembra che tutto funzioni. Adesso vorrei fare una prova con il famigerato bug dei 64kB. Ora ricerco lo sketch di astrobeed e lo compilo...
Questa poi... ho caricato lo sketch, ho scelto Arduino Mega2560, ho cliccato su "compile" e mi è venuto fuori questo errore:
avr-gcc: error: unrecognized command line option '-assembler-with-cpp'
E da chi l'ha avuto quel parametro? Gliel'ha passato l'IDE? E perché sul Blink non l'ha passato?
Ora devo uscire (dentista + lavoro) non ho tempo per indagare, se qualcuno vuol fare qualche prova e far sapere qui cos'ha ottenuto, possiamo confrontare le gioie ed i dolori 
Non ci siamo.... la toolchain Avr basata su avr-gcc 4.7 è un PACCO.
Oggi per caso, sviluppando la funzione delaySeconds, mi sono accorto che avr-binutils 2.22 è ancora affetta dal famigerato bug di delay/millis che non fa avanzare le funzioni temporali di Arduino. Pazzesco! :0
Ho rimesso la toolchain con le patch Atmel.
Sei tanto ostinato che prima o poi ce la farai e leggeremo il tanto sospirato EUREKA! XD
Disponibile la nuova toolchian per Linux 3.4.1 --> http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx
Contiene:
AVR 32-bit GNU Binutils 2.22 - Binary utilities for AVR 32-bit target (including assembler, linker, etc.)
AVR 32-bit GNU Compiler Collection (avr32-gcc) 4.4.3 - C language and C++ language compiler for AVR 32-bit target.
Newlib (for AVR 32-bit) 1.16.0 - Standard C Library for AVR 32-bit
Codice sorgente disponibile qui --> http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1/avr32/
@Leo:
Binutils dovrebbe essere patchato. 
Uhm... non sapevo di questa nuova toolchain ufficiale Atmel... son curioso di provarla....
2 note dolenti:
il .tar.gz con i binari compilati è inscaricabile: arriva un archivio corrotto di un'ottantina di byte. Bisogna prelevare i sorgenti da
http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1/avr/
e poi compilarli (devo ancora finire il download)
resta il bug dell'accesso a dati posti oltre il limite dei 128 kB:
For Mega and Xmega devices, program memory images beyond 128KBytes have limitations and may not work
for few cases
Uhm... o sono io stanco oppure le istruzioni per compilare i sorgenti sono molto fumose.... qualcuno ha capito come fare?
leo72:
Uhm... o sono io stanco oppure le istruzioni per compilare i sorgenti sono molto fumose.... qualcuno ha capito come fare?
Forse siamo stanchi entrambe, ma il SOURCES.README lascia a desiderare. Comunque mi pare di capire che puoi scaricare i sorgenti da loro (forse già patchati) oppure patchare i sorgenti vanilla dei rispettivi sviluppatori, cioè sarebbe a dire scaricare gcc-4.6.2 e applicare le patch di atmel, stessa cosa per tutti gli altri pacchetti sorgente vanilla. Come vedi le patch sono cresciute di numero quindi ci hanno lavorato parecchio, ma al momento potrebbe essereci ancora il problema dei 128kb. Quindi io dico che è meglio aspettare la nuova release, tanto quella precedente di atmel va bene almeno per me lavora tranquillamente.
Ciao.
Aggiornamento.
Adesso sto usando la toolchain ufficiale Atmel 3.4.1. Quella precompilata da Atmel, però. Perché compilare i sorgenti è un calvario: ci sono diverse cose da aggiungere sul sistema, e non mi andava di installare centinaia di MB di roba 
Ho aspettato 1 giorno ed i link ora funzionano, sia quelli a 32 che a 64 bit.
Riassumo come fare:
andare a questa pagina:
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx
scegliere la toolchain AVR8 (l'AVR32 è per i micro a 32 bit) compatibile con l'architettura del proprio SO (a 32 o 64 bit)
riempire il form con i dati richiesti: mettete un indirizzo e-mail real perché altrimenti non vi arriva il link :P. Per "Company" mettete quel che vi pare, io ho messo "MyHome" 
aprite il vostro client di posta. Dopo qualche minuto arriva un messaggio con un link da cliccare per confermare la registrazione. Questo vi porta alla pagina di download
una volta scaricato il pacchetto (sono circa 80 MB), scompattatelo.
Adesso va sostituita alla toolchain distribuita con l'IDE 1.x. Aprite la cartella dove avete l'IDE di Arduino (normalmente arduino-1.0.1) ed entrate in /hardware/tools
dentro a questa cartella ne trovate una denominata /avr: questa contiene la toolchain distribuita con l'IDE. Rinominatela in /avr.old.
create una nuova cartella /avr ed entrateci. E' vuota, in questo momento.
ora entrate nella cartella dove si sono scompattati i binari della toolchain che avete scaricato (punto 5) e copiate tutte le sottocartelle presenti nella nuova cartella /avr che avete creato al punto 8.
un'ultima modifica se usate il core Tiny. Entrate in /hardware/tiny/cores/tiny ed editate il file wiring.h. Intorno alla riga 136 commentate la riga che inizia con #define round(x) in modo che alla fine risulti così:
//#define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
Questa modifica (che forse dovrete replicare anche sui file wiring.h di altri core, se ne avete) serve per sistemare un bug sulla gestione di questa funzione matematica, funzione che si replica nel delay.h a causa dell'include della libreria matematica che c'è in questo file.
Un solo bug, per ora. Ancora non sono riuscito a compilare lo sketch di test del bug dei 64 kB che aveva preparato tempo fa astrobeed. Compilando per Atmega2560 ottengo:
avr-gcc: error: unrecognized option '-assembler-with-cpp'
Immagino che sia causato da qualche parametro passato dall'IDE ma non so come risolvere.
Grazie per la guida Leo, proverò su un pc fresco di installazione (kubuntu 11.04).
Ho messo su un hard disk separato anche un'installazione di kubuntu 12.04 perchè dicono vale la pena di provarlo; ho visto che nei repository c'è l'ide 1.0.1 ma proprio non riesco a conviverci... che tu sappia c'è la possibilità di installarci anche l'ide 0022 senza conflitti vari?
leo, l'errore è che passi al compilatore il parametro "-assembler-with-cpp", togli quello e tutto fila liscio. Se stai usando l'ide arduino, forse trovi le opzioni al compilatore nel preferencies.txt
@pelletta:
Personalmente non uso gli IDE dei repo ma solo quelli scaricati dal sito di Arduino. Questo perché così non devo installare nulla, non ho pacchetti da gestire, scompatto solo l'archivio nei miei Documenti e poi creo un collegamento sulla scrivania. In questo modo posso tenere le 2 versioni dell'IDE senza problemi: esse condivideranno solo il file delle preferenze.
Devi tenere a mente che la 1.0.1 non necessita della toolchain installata sul sistema perché ce l'ha integrata mentre la 0022 la vuole. Però se la installi per la 0022 poi essa viene usata anche dalla 1.0.1: se non ricordo male, la 1.0.1 usa la toolchain integrata solo se non la trova sul sistema.
Un "nota bene".
Ultimamente la 0022 non la uso quasi più, alla 1.0.1 ormai hanno convertito quasi tutte le lib.
lesto:
leo, l'errore è che passi al compilatore il parametro "-assembler-with-cpp", togli quello e tutto fila liscio. Se stai usando l'ide arduino, forse trovi le opzioni al compilatore nel preferencies.txt
Che sia errato il parametro lo so, l'ho scritto anch'io XD
Ma lo passa l'IDE, non io. E, come ho detto, non so dove si editino le opzioni (non sono nel file preferences.txt).
hai ragione, è hardcopdato in "./app/src/processing/app/debug/Compiler.java", riga 550;
static private List getCommandCompilerS(String avrBasePath, List includePaths,
String sourceName, String objectName, Map<String, String> boardPreferences) {
List baseCommandCompiler = new ArrayList(Arrays.asList(new String[] {
avrBasePath + "avr-gcc",
"-c", // compile, don't link
"-g", // include debugging info (so errors include line numbers)
"-assembler-with-cpp",
"-mmcu=" + boardPreferences.get("build.mcu"),
"-DF_CPU=" + boardPreferences.get("build.f_cpu"),
"-DARDUINO=" + Base.REVISION,
"-DUSB_VID=" + boardPreferences.get("build.vid"),
"-DUSB_PID=" + boardPreferences.get("build.pid"),
}));
for (int i = 0; i < includePaths.size(); i++) {
baseCommandCompiler.add("-I" + (String) includePaths.get(i));
}
baseCommandCompiler.add(sourceName);
baseCommandCompiler.add("-o"+ objectName);
return baseCommandCompiler;
}
da combiare in
static private List getCommandCompilerS(String avrBasePath, List includePaths,
String sourceName, String objectName, Map<String, String> boardPreferences) {
List baseCommandCompiler = new ArrayList(Arrays.asList(new String[] {
avrBasePath + "avr-gcc",
"-c", // compile, don't link
"-g", // include debugging info (so errors include line numbers)
"-mmcu=" + boardPreferences.get("build.mcu"),
"-DF_CPU=" + boardPreferences.get("build.f_cpu"),
"-DARDUINO=" + Base.REVISION,
"-DUSB_VID=" + boardPreferences.get("build.vid"),
"-DUSB_PID=" + boardPreferences.get("build.pid"),
}));
for (int i = 0; i < includePaths.size(); i++) {
baseCommandCompiler.add("-I" + (String) includePaths.get(i));
}
baseCommandCompiler.add(sourceName);
baseCommandCompiler.add("-o"+ objectName);
return baseCommandCompiler;
}
Se il comando c'è credo che serva, quindi toglierlo solo perchè da errore non mi sembra giusto.
Controllando qui (Overall Options (Using the GNU Compiler Collection (GCC))) mi sembra però che si siano dimenticati un pezzo.
il comando giusto dovrebbe essere
"-x assembler-with-cpp",
Potete provarlo e nel caso segnalare il bug?
Ci sono buone probabilità che ad Atmel non interessi il C++ e tanto meno C++/asm per cui non hanno curato questo aspetto e da qui l'errore.
Io continuo a preferire la creazione dei pacchetti nativi della distrò. Per fedora scarico la versione sorgente del pacchetto .srpms la installo nel build tree modifico il file .spec introducendo le nuove patch e poi avvio il builder di pacchetti rpmbuild attendo un po e il pacchetto è pronto per l'installazione/aggiornamento. Stessa cosa accade per ubuntu ma ovviamente i pacchetti sono .deb e il builder si chiama dpkg-buildpackage
http://manpages.ubuntu.com/manpages/lucid/man1/dpkg-buildpackage.1.html
Ovvio che il tempo necessario per ricostruire tutti i pacchetti della toolchain si allunga fino anche ad una settimana nel caso ci sia d'aggiustare qualcosa, ma ne vale la pena la maggior parte delle volte.
Ciao.