Not sure if it’s the right channel to post this, feel free to move…
I went back to a sketch that ran perfectly till a few weeks ago (still running on an esp32 board) which uses the Adafruit PN532 library. I wanted to make a trivial change in a line but at build time now I get a lot of the following errors and build fails:
.pio\libdeps\esp32dev\Adafruit PN532_ID29@1.0.2\Adafruit_PN532.h:199:29: error: ‘Adafruit_PN532::_miso’ will be initialized after [-Werror=reorder]
uint8_t _ss, _clk, _mosi, _miso;
.pio\libdeps\esp32dev\Adafruit PN532_ID29@1.0.2\Adafruit_PN532.h:199:22: error: ‘uint8_t Adafruit_PN532::_mosi’ [-Werror=reorder]
uint8_t _ss, _clk, _mosi, _miso;
.pio\libdeps\esp32dev\Adafruit PN532_ID29@1.0.2\Adafruit_PN532.cpp:127:1: error: when initialized here [-Werror=reorder]
Adafruit_PN532::Adafruit_PN532(uint8_t clk, uint8_t miso, uint8_t mosi, uint8_t ss):
Has anything changed in the last weeks w/Platformio that might explain this problem or did I break something? I tried to revert to earlier versions of the PN532 library but error is the same. Also I tried to pass -Wa,no-reorder or -Wp,no-reorder in platformio.ini to try and ignore the problem but probably not the way to do it as PlatformIO complains that it can’t find the file “no-reorder”. Any ideas?
I’ve seen that you have opened an issue in the library’s GitHub. That’s a good long-term thing.
In the short run, you can fix the library yourself by changing line 202 in
uint8_t _clk, _miso, _mosi, _ss;
It seems that PlatformIO is running with stricter compile-time checks than other environments (e.g. ESP8266 or Arduino IDE).
Thanks @manuelbl, I will try. I am trying to figure out how this behavior popped up. It did not happen in the past and trying to use old versions of the lib does not fix it. I didn’t try to rollback platformio too, though maybe someone can confirm if somehing in the pipeline changed lately?
I tried this and it fixes the compile problem, I still need to upload it to the board but it should work. Could you please explain how the declaration order of the variables makes such a difference? Also if it’s ok for you I’ll quote your fix on the github issue
In C++, member variables are initialized in the order they are declared in the class. The constructor’s member initialization list is not relevant for the order. This can lead to confusion and difficult to find bugs (in case the order is relevant and the constructor order differs from the declaration order). Therefore, most compilers will warn if the orders are different.
A few month ago, the behavior of the PlatformIO build script for ESP32 has been changed to not only issue a warning but treat it as an error:
I can’t tell you when this change became productive but it’s likely what has changed and why the library doesn’t compile anymore.
The reason for the change seems to be that idf.py (the build script of the ESP-IDF framework) uses this compiler setting as well. So by using the same setting it’s more likely that ESP32 libraries successfully compiled for the Arduino framework compile with the ESP-IDF framework as well. Unfortunately, it works against libraries built for several platforms (ESP8266, STM32 etc.).
The errors can be suppressed with the below line in
build_unflags = -Werror=reorder
Thanks for the very informative answer @manuelbl. I posted your fix on the github issue, let’s see how the library maintainers will address it.
#2707 went live in the ESP-IDF 1.0.3 (so Sep 13, 2019) release.
The stock readntag203 example doesn’t fail on the Arduino IDE with v1.0.4 of the ESP32 board support package (which is why Adafruit won’t have picked it up in their CI tests), but it does on PlatformIO with the same core version.
Thank you @manuelbl
I started to get this problem today after upgrading from python 2.7 to 3.10 AND the latest ArduinoIOTCloud at 1.5.0
This has blocked the error