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?
The standard GCC toolchain being used for the platform-espressif8266 is
aka GCC 4.8.2. As you can see from Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog, the latest version for all platforms is still 4.8.2…
However, someone developed an integration for the ESP8266-RTOS-SDK last year (Support for ESP-IDF style ESP8266_RTOS_SDK · Issue #125 · platformio/platform-espressif8266 · GitHub), during which GCC 5.2.0 was also added as a packet. So by using the documented platform_packages (docs) you should be able to use one of the packages for Windows or Mac
https://raw.githubusercontent.com/WallaceWilliam/xtensa-lx106-elf/master/manifest.json
E.g. for the Windows version, add
platform_packages =
toolchain-xtensa @ https://github.com/WallaceWilliam/xtensa-lx106-elf/raw/master/xtensa-lx106-elf-win32-1.22.0-100-ge567ec7-5.2.0.tar.gz
Or MacOs:
platform_packages =
toolchain-xtensa @ https://github.com/WallaceWilliam/xtensa-lx106-elf/raw/master/xtensa-lx106-elf-macos-1.22.0-100-ge567ec7-5.2.0.tar.gz
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.
Great that it works 
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.
For completeness, the full solution is in platformio.ini add to the [env:…] section:
build_unflags = -std=c++11
build_flags = -std=c++14
platform_packages =
toolchain-xtensa @ https://github.com/WallaceWilliam/xtensa-lx106-elf/raw/master/xtensa-lx106-elf-macos-1.22.0-100-ge567ec7-5.2.0.tar.gz
and on macOS you can build with c++14
Sorry, a noob question. I just downloaded xtensa toolchain from here and it has 5.2.0. Did I missed something?
Here’s the actual link
I have that too. But it’s not packaged as a PlatformIO toolchain
Late to the game, but still interested in finding a C++14 solution (I’m also on Mac) - I tried this:
build_unflags = -std=c++11
build_flags = -std=c++14
platform_packages =
toolchain-xtensa @ https://github.com/WallaceWilliam/xtensa-lx106-elf/raw/master/xtensa-lx106-elf-macos-1.22.0-100-ge567ec7-5.2.0.tar.gz
In installs (but strangely enough it re-installs on each pio-run):
Tool Manager: Installing https://github.com/WallaceWilliam/xtensa-lx106-elf/raw/master/xtensa-lx106-elf-macos-1.22.0-100-ge567ec7-5.2.0.tar.gz
Unpacking [####################################] 100%
Tool Manager: toolchain-xtensa @ 5.2.0+100 has been installed!
The files do appear here:
$ cd .platformio/packages/
/Users/jcw/.platformio/packages
$ ls -l toolchain-xtensa*/bin/xte*-g{++,cc}
-rwxr-xr-x 1 jcw staff 924108 Sep 3 2019 toolchain-xtensa/bin/xtensa-lx106-elf-g++
-rwxr-xr-x 1 jcw staff 920004 Sep 3 2019 toolchain-xtensa/bin/xtensa-lx106-elf-gcc
-rwxr-xr-x 1 jcw staff 924108 Sep 3 2019 toolchain-xtensa@src-71082da57b6781e9b0698b5fba9df356/bin/xtensa-lx106-elf-g++
-rwxr-xr-x 1 jcw staff 920004 Sep 3 2019 toolchain-xtensa@src-71082da57b6781e9b0698b5fba9df356/bin/xtensa-lx106-elf-gcc
But the compilers are not found for some reason:
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?
You can try using the xtensa-gcc 10.1.0 compiler (API request for searching) if the previous compiler doesn’t work for you.
Should be as easy as
[env:nodemcuv2_rtos_sdk]
platform = espressif8266
board = nodemcuv2
framework = esp8266-rtos-sdk
build_unflags = -std=c++11
build_flags = -std=c++14
platform_packages =
toolchain-xtensa @ ~2.100100.0
This also works for -std=c++17 btw.
I can also compile the Arduino-ESP8266 in C++14 mode by doing
[env:nodemcuv2_arduino]
platform = espressif8266
board = nodemcuv2
framework = arduino
build_unflags = -std=c++11
build_flags = -std=c++14 -fno-sized-deallocation
platform_packages =
toolchain-xtensa @ ~2.100100.0
btw.
Is there some security system interfering? Hm. If the above also doesn’t work there’s a problem.
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.
Fantastic! Completely solved, for reference, the relevant changes as you described:
[env]
build_unflags = -std=c++11
build_flags = -std=c++14
platform_packages = toolchain-xtensa @ ~2.100100.0
I’m super happy with this, Max. ESP8266 was tying me down to C++11. Many thanks.
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.
It could, there must just be an exception added in the PlatformIO core logic for that case – as far as I remember when they added support for the M1 ARM type, they re-released / edited all PlatformIO-owned packages to include the new info. (Platform IDE for VSCode on Mac ARM/M1? - #13 by ivankravets). Maybe I should open an issue in Issues · platformio/platformio-core · GitHub for these use-cases.
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.