The right way to declare structs in PROGMEM?

I have a structure in flash memory that several modules share access to. The header file they all use says something like

struct footype {...}; extern const struct footype foo PROGMEM;

and the definition/initialization of the structure in one of the modules looks like

const struct footype foo PROGMEM = {...};

It seems to work, but I get warnings during linking that "type of 'foo' does not mach original declaration". (There are no pointers to strings in the structure, so it's not that old problem.)

What's the right way to do this to avoid the warnings?

I just read this, you might want to have a look. How to use PROGMEM to (readably) initialize a structure

That talks about the string pointer problem, but I don' t see that it helps with the warning messages that I'm getting.

This will help... https://www.youtube.com/watch?v=tdQL_7osGzc

I get warnings during linking that "type of 'foo' does not mach original declaration".

An example I put together works fine for me. Probably something else is wrong.

Could you trim down a sketch that exhibits the problem, zip it up, and attach it to the thread?

Well, in trying to make a trivial test case I got a lead on what the problem is, and it's out of left field: the module which has the structure definition has a ".c" file extension instead of a ".cpp" file extension! I don't entirely understand the implications of that (I'm really writing in the C subset of C++), but at least now I can fix it.

Thanks for pushing me to work on a simple test that shows the problem.

I had my suspicions that you would figure out what was wrong in the process of simplifying it...

It's not the error I would have expected from a C/C++ error related to name-mangling, but it doesn't really surprise me...

What do you mean with “several modules” ? Not used to the Arduino way yet ?
The *.ino files are combined together, you only need to include a *.h file in the first *.ino file.

In C++, the struct footype {…}; is already a typedef.

The Arduino pre-processes the files before compiling it.
That preprocessor tries to be “smart”, and sometimes that gets in the way. So it might be needed to make a workaround for the preprocessor, even if the code itself is fine.