Espressif has a toolchain out that uses gcc 5.2.0, which supports C++14, which I need to use. But the toolchain being used by platformio is 4.8.2. I saw someone mention in a post somewhere that their platformio ESP8266 installation showed 5.2.0 for the installed gcc.
I’ve tried uninstalling and reinstalling platformio in VSCode to no avail. Is there some other update technique I need to use to the the right toolchain?
to the platformio.ini. If you are using Linux, you would need to download the official toolchain, add the appropiate package.json to the archive (refer to the ones inside the packages listed above), and reupload the archiv somewhere (e.g. github). Then you can use the same form as above to point to the archive download.
Thanks for the response. I’m on Mac, but his site says this is for both Win and Mac. But when I add that line I get “sh: xtensa-lx106-elf-g++: command not found”. Do I need to download that package and put it somewhere first?
I have the official Espressif toolchain I installed with the RTOS SDK. Can I just point my build at that toolcahain?
The executable is definitely there, as xtensa-lx106-elf-g++ (+.exe in Windows). I’ll double check.
The idea of PIO is to explicitly not rely on system tools but its internal package repository, so that’s not straightforward. What is possible as a hack though is to remove the platform_packages again so that it uses the default toolchain-xtensa, but locally replace the files (<home path>/.platformio/packages/toolchain-xtensa) with the files from your updated system compiler. That is not portable however and I’ll double check if the platform_packages way works for me, at least on Windows 10 (as I have no Mac).
Sorry, my bad. I didn’t look at the path closely enough or I would have seen the “win32” in there. I looked at the site and there is an equivalent “macos” version. I switched to that and it’s working now. Thanks for your help
Alright great, that was also my thought (unable to execute the binary due to some issues). I tested in locally on my Windows machine and it worked first try. I explicitly added the Mac path in the original post.
I’m getting the 5.2.0 compiler since it accepts ‘-std=c++14’, but it still seems to be using the C++11 include files. I’m trying to use the chrono_literals namespace, but I get an error that it doesn’t exist. The version of in the xtensa package that has the 5.2 compiler also has the 5.2 includes. But apparently I’m not using those. I still need to figure that one out
Ok, all is well. This post is just to describe my final issue. I added ‘build_flags = -std=c++14’ to platformio.ini. But since c++11 is the default I also had to undefine that flag with ‘build_unflags = -std=c++11’. All is well now.
Building in release mode
Compiling .pio/build/wemos/src/main.o
sh: xtensa-lx106-elf-g++: command not found
Compiling /Users/jcw/.platformio/packages/framework-esp8266-rtos-sdk/lib/driver/driver/gpio.o
sh: xtensa-lx106-elf-gcc: command not found
Compiling /Users/jcw/.platformio/packages/framework-esp8266-rtos-sdk/lib/driver/driver/hw_timer.o
sh: xtensa-lx106-elf-gcc: command not found
[etc...]
Running the compilers with -v, they report all version info, so the binaries seem to be ok.
I don’t understand what’s going on. I used pio run -v. Is there a way to debug this?
Thanks - I’ll try this! Well, maybe it’s because right now I’m trying this on an M1-based MacBook Air, although so far I’ve not seen a single issue with Rosetta 2 kicking in for x86_64 support.
Ahhh. That it’s being run on an M1 is critical. For that to work the manifest file (package.json) must also be adapted to declare darwin_arm64 compatibility. The package was probably downloaded but PlatformIO did include its path for the build process because it rejected it internally on a system architecture mismatch (darwin_x86_64 vs darwin_arm64). Sadly for a fix they would have to re-release the GCC 5.2.0 package that is being used here with a fixed package.json – but since 10.1.0 is now available in the normal PlatformIO repos and works and supports even newer language versions, there shouldn’t be a need for that.
Ok, clear. Given the “dual” nature of M1, couldn’t PIO accept x86_64 binaries as well, when on M1?
But I agree - water under the bridge. If / when 10.1.0 becomes the default, it’ll all be history.
Here’s a belated big thank you to @maxgerhardt for opening up the C++17 world to me.
It’s absolutely amazing how C++ has evolved to an almost Pythonic feature set.