Support for C++20 ranges

[LeCyberDucky]

Hey there!

Long story short, I'm looking for C++20 ranges support when programming my ESP32-S3 with the Arduino framework.

I'm working on a project for an ESP32-S3-based board (the LilyGo T-Display-S3), and, when trying to use the C++20 ranges library, I run into the error:

fatal error: ranges: No such file or directory

I'm using PlatformIO to develop this project. An initial question in the PlatformIO forum, lead me to the ESP32 Arduino forum, which has subsequently lead me to this place.

Along this adventure, I have come across this seemingly similar issue about support for C++20 chrono: https://github.com/espressif/esp-idf/issues/12914#issuecomment-1873703047

It is mentioned that this will be supported starting with GCC14. A quick look at https://en.cppreference.com/w/cpp/compiler_support reveals that "The One Ranges Proposal" should be supported from GCC10. And I can see that the latest release in this repository upgrades the GCC version to 13.2.0. So, I should be able to use ranges, no?

All of this has me quite confused, especially considering that I'm simply trying to port a project that works on an ESP8266. Could somebody explain to me what is going wrong, and if there's anything I can do to fix it?

It is not quite obvious to me which compiler I'm actually using. My PlatformIO.ini looks like this:

[env:lilygo-t-display-s3]
; platform = espressif32
platform = https://github.com/platformio/platform-espressif32.git
board = lilygo-t-display-s3
framework = arduino
build_unflags = -std=gnu++11
build_flags = -std=gnu++2a //https://community.platformio.org/t/which-c-standard-am-i-using/24597/4

With that, I get the following information when trying to build my project:

PACKAGES:
 - framework-arduinoespressif32 @ 3.20014.231204 (2.0.14)
 - tool-esptoolpy @ 1.40501.0 (4.5.1)
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch5
 - toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5

Kind regards

[igrr]

Looks like you are using Arduino-esp32 core version 2.0.14, which is based on ESP-IDF v4.x, which uses GCC 8.4.x for its toolchain. Newer IDF versions are already using the newer versions of GCC (12.2, 13.2). The upcoming Arduino-esp32 v3.0.0 release will be based on IDF v5.1.x, so the functionality you are looking for will be available there. Here is the project which tracks the 3.0.0 release of Arduino-esp32 core: https://github.com/orgs/espressif/projects/3/views/14

[LeCyberDucky]

Thank you for the very quick and helpful reply!

Whoa, that's quite a jump in the GCC versions. I gather that pre-releases of version 3.0.0 are available here: https://github.com/espressif/arduino-esp32/releases

Do you know whether it would be possible to change my setup to use that?

[igrr]

Platformio does not yet have support for arduino-esp32 v3.0.0 pre-releases, however there is a fork maintained by Tasmota which already supports this version: https://github.com/Jason2866/platform-espressif32. Perhaps you can try it and see if that works.

[LeCyberDucky]

Alright, that sounds great, I'll give it a try! Thanks for pointing me in the right direction.

I suppose we can close this issue then :)

[robertlipe]

I just crashed into this hard. I was questioning my sanity because I "knew" that the latest updates used IDF 5.1 and IDF 5.1 used GCC13 and I'd recently confirmed that my g++ brothers are indeed gcc13 with a correspondingly recent libstdc++. I even knew that xtensa-esp32s3-elf-g++ -c -std=gnu++2a src/tokenize.cc worked, but platformio couldn't compile my ranges even though the header is clearly there. But nooooo. pio run SAYS it's running xtensa-esp32s3-elf-g++, but it seems to actually be running an ancient copy of xtensa-esp32s3-elf-g++ squirreled away that's nowhere near where my idf.py PATHED for me. Sure enough, up at the top, I see: ^[[0m - framework-arduinoespressif32 @ 3.20014.231204 (2.0.14) ^M ^[[0m - tool-esptoolpy @ 1.40501.0 (4.5.1) ^M ^[[0m - toolchain-riscv32-esp @ 8.4.0+2021r2-patch5 ^M ^[[0m - toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5^M

I don't even know where it's finding that: $ find .espressif -name xtensa-esp32s3-elf-g++

.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp32s3-elf-g++

[ hammer drops ] Oh. Platformio squirrels away it OWN copies instead of using what's in esp-idf. :-( It's not calling exec() on what it's printing at all; it's seemingly building a separate path and using THAT.

$ find .platformio -name xtensa-esp32s3-elf-g++

.platformio/packages/toolchain-xtensa-esp32s3@8.4.0+2021r2-patch5/bin/xtensa-esp32s3-elf-g++ .platformio/packages/toolchain-xtensa-esp32s3/bin/xtensa-esp32s3-elf-g++

It's in $HOME and hidden, so it doesn't show up in finder or locate. Awesome...and it's not been updated since 2018, which explains why {fmt} and ranges and such are problematic.

I didn't understand that a project linking a compatibility shim with AVR would hold back the toolchain like this. That's pretty wild.

The second line of https://github.com/platformio/platform-espressif32/releases says "updated to IDF 5.2.1" and that doc says "This has now been upgraded to GCC 13.2.0 " ... but it seems to still be using a 6 y/o g++ behind the covers. It still claims pretty modern C++23 support in https://docs.espressif.com/projects/esp-idf/en/v5.1.3/esp32/api-guides/cplusplus.html#cplusplus-limitations

https://blog.espressif.com/announcing-the-arduino-esp32-core-version-3-0-0-3bf9f24e20d4 shows the 3.0 transition for that package should have embraced IDF 5.1 months ago and https://github.com/orgs/espressif/projects/3/views/14 looks more empty than not. I've updated every IDF and PIO package I can find.

I feel like I'm missing a joke somewhere in all the layers of abstraction. I have a g++ in my path that's not being used. It reports framework-arduinoespressif32 version 3.2. Is there some cached value or .ini tweak I need to make to get it to really match what esp-idf/export.sh is reporting? xtensa-esp32-elf-g++ --version xtensa-esp-elf-g++ (crosstool-NG esp-13.2.0_20230928) 13.2.0 with the same for xtensa-esp32s3-elf-gcc, of course.

I know this is an older (and closed) report, but is the current advice for anyone needing a g++ from the last six years still to go to another toolchain?

Sorry if I'm sounding cranky but all these independently maintained layers hiding the details of the other layers, but missing six years worth of language updates is pretty frustrating. (We experience UNIX dudes tend to always sound cranky at all this stuff in the way of our Makefiles. :-) ) Updating IDF to 5.1.3, pio upgrade 6.1.5, and all the pio pkg updates doesn't seem to be updating the right things.

Something between ESP_IDF and this pio wrapper that seems to be sticking on old versions or I've missed a config change.

How did you get back to an actively maintaned chain, @LeCyberDucky ?

Thanx!

[LeCyberDucky]

@robertlipe I agree that it's very frustrating to deal with these layers upon layers of abstractions.

I have not had the time to look at this for a little while now, so I'm a bit out of the loop and therefore not sure of how much help I can be.

As I recall, however, I ended up making use of this: https://github.com/platformio/platform-espressif32/pull/1281, which let me compile the stuff I wanted to compile. Is that of any help?

My very cluttered platformio.ini kinda documents what I've been through, in case that is of any interest:

; PlatformIO Project Configuration File
;
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[env:lilygo-t-display-s3]
; Using a custom toolchain to use GCC 13 instead of 8 and get access to C++20
; https://community.platformio.org/t/c-20-ranges-library-fatal-error-ranges-no-such-file-or-directory/37771
; https://esp32.com/viewtopic.php?f=19&t=37770
; https://github.com/espressif/crosstool-NG/issues/48
; https://github.com/Jason2866/platform-espressif32
; https://github.com/orgs/espressif/projects/3/views/14
; https://community.platformio.org/t/which-c-standard-am-i-using/24597
; platform = espressif32
; platform = https://github.com/platformio/platform-espressif32.git 
; platform = https://github.com/tasmota/platform-espressif32/releases/download/2024.01.10/platform-espressif32.zip
;https://github.com/platformio/platform-espressif32/pull/1281
platform = https://github.com/sgryphon/platform-espressif32.git#sgryphon/add-esp32-arduino-libs
platform_packages =
    platformio/framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#master
    platformio/framework-arduinoespressif32-libs @ https://github.com/espressif/esp32-arduino-libs.git#idf-release/v5.1
; https://community.platformio.org/t/esp32-with-c-20-for-std-span/35279/
; https://registry.platformio.org/tools/espressif/toolchain-riscv32-esp/versions
; https://registry.platformio.org/tools/espressif/toolchain-xtensa-esp32s3/versions
; platform_packages = espressif/toolchain-xtensa-esp32s3@12.2.0+20230208
board = lilygo-t-display-s3
framework = arduino
; framework = https://github.com/espressif/arduino-esp32.git
build_unflags = -std=gnu++11
build_flags = -std=gnu++2b ;https://community.platformio.org/t/which-c-standard-am-i-using/24597/4
              -D LV_CONF_INCLUDE_SIMPLE
              -D LV_CONF_SKIP ; Configure LVGL in platformio.ini instead of lv_conf.h - https://github.com/lvgl/lv_platformio/issues/28
              ; Configuration instructions: https://docs.lvgl.io/master/porting/project.html
              -D LV_COLOR_DEPTH=16
              -D LV_USE_ST7789
              -D LV_USE_LOG
              -D LV_LOG_LEVEL=LV_LOG_LEVEL_INFO
              -D LV_USE_ASSERT_NULL
lib_deps = lvgl = https://github.com/lvgl/lvgl.git@^9.0.0
        ;    lv_drivers = https://github.com/lvgl/lv_drivers
monitor_filters = esp32_exception_decoder, colorize, time ; debug
build_type = debug

[robertlipe]

Thanx for the helpful reply. That was the nudge I needed. As you saw, I ran into other issues caused by a bump in the 3.0 RC, but am now moving forward. Incidentally, I saw your name in other LED strip and S3 projects in recent days, so we're running in similar circles.

I'm very much with you on the layering issues. It's a huge mess...and it's clear that at least some of the problems holding back progress on 3.0 aren't all technical.

I appreciate the hand!