Since that fix won’t work on linux, I dug a bit deeper.
The loss of the EEWE define happened in revision 1974 of eeprom.h
which was on June 5, 2009
Previously, older avr libC versions of eeprom.h defined EEWE as EEPE if EEWE didn’t exist.
But the real solution is that the bootloader code should not be using EEWE at all.
The code should be modified to use eeprom_is_ready() or eeprom_busy_wait() from eeprom.h instead.
eeprom_is_ready() has existed in all revisions of eeprom.h (first rev was July 4, 2002)
eeprom_busy_wait() was added/created Feb 26, 2004 in revision 440
Now there is some very strange code in the bootloader:
/* the current avr-libc eeprom functions do not support the ATmega168 */
/* own eeprom write/read functions are used instead */
#if !defined(__AVR_ATmega168__) || !defined(__AVR_ATmega328P__)
This always ends up including <avr/eeprom.h>
(luckily so, as it was needed for the old EEWE define)
It looks like this originally was attempting to avoid including <avr/eeprom.h> when
building for the ATmega168, but somebody screwed up when adding in 328P support.
Since <avr/eeprom.h> is always included, and has been for quite some time,
the ifdef around the <avr/eeprom.h> include should
be removed to eliminate any potential confusion in the future and having some poor soul attempt to
“fix” this ifdef which would break the code.
So how can we get the arduino team to update/cleanup the bootloader code to
clean up the eeprom.h include and
use the eeprom macros in eeprom.h so it works in all environments and all versions of the tools?
It is a very quick and simply update/fix and should have zero impact on the generated code.