EEPROMex build fails on newer avr-g++

[deltaphi]

EEPROMex can no longer be built using newer versions of gcc. It builds successefully on the Arduino-supplied avr-gcc 4.3, however building it using arduino-mk on a gcc 4.7 fails. GCC complains about conflicting definitions of EEPROM in EEPROMEx/EEPROMex.h:159.

In attempt to track this down further I ran the build in the Arduino IDE with full output. On gcc 4.3 this is a warning - possibly resulting in undefined behaviour? (I.e., sometimes EEPROM is used, sometimes EEPROMex)

So it seems that using EEPROMex as a drop-in replacement for EEPROM is no longer possible and at least the name of the global variable should be changed, e.g. from EEPROM to EEPROMex.

Another (possibly better) solution might be to replicate the necessary code from EEPROM in EEPROMex and eliminate the #include . Otherwise, an instance of the EEPROM library may hang around costing valuable memory (Disclaimer: I'm no expert on what optimizations GCC can and will do in this case).

[thijse]

Hi deltaphi,

Thanks for finding this! I am in the process of reworking EEPROMex so that it can use backends for all kinds of storage (internal EEPROM, RAM on a RTC, external EEPROM), I will see if I can easily remove the EEPROM include in EEPROMex, but I don't think that will be a problem. Can I ask you to try it out when I've checked it in?

Cheers,

Thijs

On Tue, Jul 9, 2013 at 9:54 PM, deltaphi notifications@github.com wrote:

EEPROMex can no longer be built using newer versions of gcc. It builds successefully on the Arduino-supplied avr-gcc 4.3, however building it using arduino-mk on a gcc 4.7 fails. GCC complains about conflicting definitions of EEPROM in EEPROMEx/EEPROMex.h:159.

In attempt to track this down further I ran the build in the Arduino IDE with full output. On gcc 4.3 this is a warning - possibly resulting in undefined behaviour? (I.e., sometimes EEPROM is used, sometimes EEPROMex)

So it seems that using EEPROMex as a drop-in replacement for EEPROM is no longer possible and at least the name of the global variable should be changed, e.g. from EEPROM to EEPROMex.

Another (possibly better) solution might be to replicate the necessary code from EEPROM in EEPROMex and eliminate the #include . Otherwise, an instance of the EEPROM library may hang around costing valuable memory (Disclaimer: I'm no expert on what optimizations GCC can and will do in this case).

— Reply to this email directly or view it on GitHubhttps://github.com/thijse/Arduino-Libraries/issues/3 .

[deltaphi]

Sure, no problem.

Regards Damian

[blemasle]

Hi Thijs,

I'm also very interested in your rewriting of EEPROMEx, as I'll soon start a project with an external EEPROM. Moreover, my old version of that project that works with standard EEPROMEx does not compile anymore on the new avr-g++ as delaphi find out. So I'm also interested in the new version EEPROMEx version as a more reliable solution than altering the original source files.

Cheers, blemasle

NB : I reproduce the issue on my own environment, which use avr-gcc 4.3.5. So it didn't start with v4.7