When I add the Adafruit SSD1306 library (which supports small OLED displays) into a working sketch, the compiler says:
C:\Users\Stew\Documents\Arduino\libraries\Adafruit_SSD1306\Adafruit_SSD1306.cpp:19:26: fatal error: avr/pgmspace.h: No such file or directory
The line of code the error is referring to is calling another Adafruit required OLED support library: #include <Adafruit_GFX.h>
I have many pgmspace.h files on my computer. I also have many avr folders on my system - several of which hold some of those pgmspace.h files.
Why do I have so many of these?
How do I determine where the compiler is looking for this: avr/pgmspace.h ?
Which of the many pgmspace.h files is the one it needs in this case, and why isn't it finding it?
Is it an avr-based board? The avr/pgmspace library only works on avr parts. When compiling for other architectures, different techniques are used to access the flash; consult the documentation for the board you're using (or the third party board package, if using one of those). Since the library is architecture specific (in fact, they're in avrlibc, which is part of the compiler), the IDE is smart enough to not attempt to use if if you're compiling for a part for which it won't work (which would generate a much more confusing set of undefined reference errors if it tried)
For example, on megaavr (Uno Wifi Rev. 2, Nano Every, stuff supported by my megaTinyCore), you just declare the variables const, and use them normally, and the compiler will automatically put them in flash and not copy them to ram* (though you can still declare variables PROGMEM, and then access them with pgm_read_* functions). There's a different way to do it for the ESP's, and on the SAMD boards, and on the boards with other architectures (but I rarely use these with Arduino so I couldn't say OtoMH what they are)
*If you're curious about why the difference between megaavr and classic avr (but this is probably way more than you need or want to know): on classic avr, flash and ram are in separate address spaces, so a special function is needed to read from the flash; unless you declare variables PROGMEM, the assumption is that you'll access them like a normal variable, meaning they have to be copied to RAM (because normal variable access can only look at RAM). On megaavr, both flash and ram use the same 16-bit address space, so the flash can be read as easily as ram. This is probably why the m4809 (as used on nano every, uno wifi rev 2) is the top end megaavr part right now: 48k flash + 6k ram + the registers pretty much fills that address space, so the next logical size, 64k of flash, wouldn't work in this paradigm - there would be no space in the address space for the registers and ram)
DrAzzy:
The avr/pgmspace library only works on avr parts.
Many 3rd party cores provide avr pgmspace compatibility and do provide a pgmspace.h header file in an avr subdirectory that is on the include path.
sam, samd, stm32f4, STM32, Microsoft, Intel, Chipkit, teensy3, esp8266
The esp32 also provides a pgmspace.h file but it isn't under an "avr" subdirectory, so that may cause an issue on that core.