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 <EEPROM.h>. 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//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