error: no matching function for call to 'min(size_t&, int&)'

[bughaver]

What happened?

unable to build on tag v0.14.2 or main using Platformio

To Reproduce Bug

Try to build/upload d1_mini_ota using Platformio

Expected Behavior

Successful build

Install Method

Self-Compiled

What version of WLED?

v0.14.2 and main

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

Compiling .pio\build\d1_mini_ota\lib5c3\ESP8266SdFat\ExFatLib\ExFatFile.cpp.o
.pio\libdeps\d1_mini_ota\ESPAsyncWebServerWLED\src\WebResponses.cpp: In member function 'virtual size_t AsyncAbstractResponse::_ack(AsyncWebServerRequest*, size_t, uint32_t)':
.pio\libdeps\d1_mini_ota\ESPAsyncWebServerWLED\src\WebResponses.cpp:366:43: warning: comparison of integer expressions of different signedness: 'size_t' {aka 'unsigned int'} and 'int' [-Wsign-compare]
  366 |       if ((old_space < outLen) || (outLen > max_block_size)) {
      |                                    ~~~~~~~^~~~~~~~~~~~~~~~
.pio\libdeps\d1_mini_ota\ESPAsyncWebServerWLED\src\WebResponses.cpp:370:51: error: no matching function for call to 'min(size_t&, int&)'
  370 |           outLen = std::min(outLen, max_block_size);

Anything else?

Also see this error some times?

*** [wled00\wled00.ino.cpp] TypeError : unsupported operand type(s) for -: 'float' and 'NoneType'

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

Please use WLED forum or Discord for help and support questions.
Closing.

[softhack007]

WebResponses.cpp:370:51: error: no matching function for call to 'min(size_t&, int&)'

@willmmiles it looks like the line in question was introduced by this commit

Aircoookie/ESPAsyncWebServer@c99bca5#diff-646b25b11691c11dce25529e3abce843f0ba4bd07ab75ec9eee7e72b06dbf13fR345

I think the solution would be to replace auto in line 345 with size_t.

Any way using auto in C/C++ code is kind of bug-prone, because the type is not in the developers control any more, leading to strage effect like this one - where std:min could not instantiated a template because both arguments are expected to be of exactly the same type.

[willmmiles]

Any way using auto in C/C++ code is kind of bug-prone, because the type is not in the developers control any more, leading to strage effect like this one - where std:min could not instantiated a template because both arguments are expected to be of exactly the same type.

Hard disagree - this is exactly the kind of thing I want to catch, I don't want to blindly override type mismatches. This code compiles correctly on my system in a clean checkout - why? What's different about @lsaadeh's environment?

@lsaadeh - I am interested in fixing this. Can you please run pio pkg list -e d1_mini_ota in your WLED checkout and post the output? I'd like to see which package you have that differs from my system.

[blazoncek]

Haha.
@softhack007 we are getting old, newer generation (or C++ generation) prefers AAA (Almost Always Auto).

[bughaver]

@willmmiles

This is the output

PlatformIO IDE: v3.3.3

PS C:\Dev\WLED> pio pkg list -e d1_mini_ota
Resolving d1_mini_ota dependencies...
Platform espressif8266 @ 4.2.0 (required: espressif8266 @ 4.2.0)
├── framework-arduinoespressif8266 @ 3.30002.0 (required: platformio/framework-arduinoespressif8266 @ *)
├── tool-esptool @ 1.413.0 (required: platformio/tool-esptool @ *)
├── tool-esptoolpy @ 1.30100.210531 (required: platformio/tool-esptoolpy @ *)
├── tool-mklittlefs @ 1.203.210628 (required: platformio/tool-mklittlefs @ ~1.203.0)
├── tool-mkspiffs @ 1.200.0 (required: platformio/tool-mkspiffs @ ~1.200.0)
└── toolchain-xtensa @ 2.100300.220621 (required: platformio/toolchain-xtensa @ ~2.100300.220621)

Libraries
├── ESPAsyncTCP @ 1.2.2 (required: ESPAsyncTCP @ 1.2.2)
├── ESPAsyncUDP @ 0.0.0-alpha+sha.697c75a025 (required: ESPAsyncUDP)
├── ESPAsyncWebServerWLED @ 2.2.0+sha.a68a18c (required: git+https://github.com/Aircoookie/ESPAsyncWebServer.git @ ^2.1.0)
├── FastLED @ 3.6.0 (required: fastled/FastLED @ 3.6.0)
├── IRremoteESP8266 @ 2.8.2 (required: IRremoteESP8266 @ 2.8.2)
└── NeoPixelBus @ 2.7.5 (required: makuna/NeoPixelBus @ 2.7.5)

[blazoncek]

Why do you use platform 4.2.0? You should use 4.2.1.
arduino_core_3_1_2 = espressif8266@4.2.1

[bughaver]

@blazoncek looks to be defined here as 4.2.0 https://github.com/Aircoookie/WLED/blob/main/platformio.ini#L66
I'm just using defaults and this to overwrite

[platformio]
default_envs = d1_mini_ota

[env:d1_mini_ota]
board = d1_mini
upload_protocol = espota
upload_port = "xx.xx.xx.xx"
platform = ${common.platform_wled_default}
platform_packages = ${common.platform_packages}
board_build.ldscript = ${common.ldscript_4m1m}
build_unflags = ${common.build_unflags}
build_flags = ${common.build_flags_esp8266}
   -D USERMOD_PIRSWITCH
lib_deps = ${esp8266.lib_deps}

edit: getting the same error with the below added to override

[common]
arduino_core_3_1_2 = espressif8266@4.2.1

PS C:\Dev\WLED> pio pkg list -e d1_mini_ota
Resolving d1_mini_ota dependencies...
Platform espressif8266 @ 4.2.1 (required: espressif8266 @ 4.2.1)
├── framework-arduinoespressif8266 @ 3.30002.0 (required: platformio/framework-arduinoespressif8266 @ *)
├── tool-esptool @ 1.413.0 (required: platformio/tool-esptool @ *)
├── tool-esptoolpy @ 1.30100.210531 (required: platformio/tool-esptoolpy @ *)
├── tool-mklittlefs @ 1.203.210628 (required: platformio/tool-mklittlefs @ ~1.203.0)
├── tool-mkspiffs @ 1.200.0 (required: platformio/tool-mkspiffs @ ~1.200.0)
└── toolchain-xtensa @ 2.100300.220621 (required: platformio/toolchain-xtensa @ ~2.100300.220621)

Libraries
├── ESPAsyncTCP @ 1.2.2 (required: ESPAsyncTCP @ 1.2.2)
├── ESPAsyncUDP @ 0.0.0-alpha+sha.697c75a025 (required: ESPAsyncUDP)
├── ESPAsyncWebServerWLED @ 2.2.0+sha.a68a18c (required: git+https://github.com/Aircoookie/ESPAsyncWebServer.git @ ^2.1.0)
├── FastLED @ 3.6.0 (required: fastled/FastLED @ 3.6.0)
├── IRremoteESP8266 @ 2.8.2 (required: IRremoteESP8266 @ 2.8.2)
└── NeoPixelBus @ 2.7.5 (required: makuna/NeoPixelBus @ 2.7.5)

[softhack007]

Re-opening as some analysis is ongoing.

[willmmiles]

Here it is: framework-arduinoespressif8266 @ 3.30002.0, my system has 3.30102.0 instead. It looks like there were a lot of changes in the ESP8266 Arduino framework v3.1 vs v3.0, including the type signature of ESP.getMaxFreeBlockSize().

Unfortunately, PlatformIO doesn't provide a mechanism for libraries to specify a dependency on a specific platform package revision. It's been feature requested - on this very platform change, no less! - but backlogged, with no expectation of work in the near future.

• https://community.platformio.org/t/specify-minimum-platform-version-in-library-json/27404
• Add semantic versioning to platforms property in library.json platformio/platformio-core#4243

@blazoncek and @softhack007 - would be a good idea to pin the ESP8266 framework version in WLED? Given the extent of the changes, it's possible this could be the source of quite a bit of divergent behaviour in different people's local builds beyond this immediate issue.

If you feel strongly that we want to support arbitrary older platform revisions, I'll add some matrix CI on AsyncWebServerWLED to make sure it works correctly. I'd spent a little time trying to get the CI up and running again anyways, this'd make it more of a priority. (As far as I'm concerned, that repo need only support the WLED requirements.)

[willmmiles]

On the entirely unrelated other note:

Also see this error some times?

*** [wled00\wled00.ino.cpp] TypeError : unsupported operand type(s) for -: 'float' and 'NoneType'

I'm using Visual Studio Code with the PlatformIO plugin. I've seen this happen if there's a race between a build process and the plugin trying to reconfigure itself. The plugin monitors for changes in platformio.ini, but not platformio_override.ini. So when the override is updated, the IDE doesn't notice until a build is started -- and then the "ide reconfigure" tries to rewrite wled00.ino.cpp while it's being compiled.

I've gotten in to the habit of whitespace-edit-and-save on platformio.ini any time I need to update platformio_override.ini to force the IDE to notice the changes. There's probably a better way, though.

[bughaver]

@willmmiles can confirm by setting the following in my platformio_override.ini that I was able to successfully build and upload

[common]
arduino_core_3_1_2 = espressif8266@4.2.1
platform_packages = platformio/framework-arduinoespressif8266 @ 3.30102.0
                    platformio/toolchain-xtensa @ ~2.100300.220621 #2.40802.200502
                    platformio/tool-esptool #@ ~1.413.0
                    platformio/tool-esptoolpy #@ ~1.30000.0

[willmmiles]

I dug a little in to this, and found out that the unversioned "platformio/framework-arduinoespressif8266" in platform_package was overriding the arduino_core selection -- essentially allowing each build system to pick whatever version of the framework it liked, based on whatever had been previously downloaded. This didn't cause problems for CI or "fresh" build systems because we just happened to want the latest version. I've opened PR #3862 to remove the unversioned entry which will allow the framework to be correctly selected via the 'platform' version.

[softhack007]

Fixed by PR #3862