Part of the issue here is the simplistic (poor) font methodology used in GLCD.
(It was inherited from its parent library ks0108). Because the fonts don't have
a separate external declaration, it creates issues when the font header is included more than once.
(like in separate modules) because the data ends up being declared & defined more than once - At some point I will fix this.
(It not as easy as it sounds since there are several font tools out there that create font files that I don't have control over)
But I think part of the issue in this case is also the way u8glib is working around some of the C++ progmem issues.
As Oliver said there are issues with PROGMEM and C++
PROGMEM often issues warnings in C++ when it shouldn't, so there have been attempts at creating
work arounds to suppress the warnings.
Some of these "work arounds" eliminate the warnings but create other issues.
Also, I'm starting to see different libraries attempt different work arounds and that can create problems as well
when used together as the work arounds are potentially incompatible with each other.
This popular "work around":
#define PROGMEM __attribute__((section(".text"))) // works on both AVR and ARM
Will break M2tklib because the two m2_rom pointers that use M2_PROGMEM in utility/m2.h create an
error if this work around done before m2.h is included.
A safer M2_PROGMEM definition would be:
#define PROGMEM __ATTR_PROGMEM__
to avoid any of those PROGMEM work arounds.
Overall, the avr-gcc PROGMEM stuff is a kludge that is quite fragile.
I've wrestled with progmem C++ issues on Arduino for quite some time.
Its a mess because of the different versions of avr-gcc and now all the work arounds
that are being used.
Oliver, we need to sync up off line.
I'm in the process of a major update of the GLCD library.
There are also some issues with the way Paul has defined his PROGMEM compatibility macro
for his teensy3 product that will more than likely affect your stuff as well.
Lets talk offline and I'll fill you in.