First of all let me say that I'd love to have opened this issue at the compiler repository, https://github.com/espressif/crosstool-NG, but opening issues is not allowed there. Since I'm attempting to compile Arduino-ESP32 this is the next fitting option.
The problem statement is as follows: I'm attempting to compile the Arduino-ESP32 framework using Espressif's G++ 8.2.0 2019r2 version, as provided in https://github.com/espressif/esp-idf/blob/master/tools/tools.json#L54.
I'm using PlatformIO with which I can automatically select this exact compiler version from its repository. I'm using this platformio.ini
[esp32]
; upgrade XTensa32 GCC/G++ compiler to 8.2.0
; use bleeding edge arduino-esp32
platform_packages =
toolchain-xtensa32 @ 2.80200.200226
framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git
[common]
build_flags =
-DESP32=1
-DARDUINO_ARCH_ESP32=1
-DBOARD_HAS_PSRAM
-std=c++17
-std=gnu++17
build_unflags =
-std=gnu++11
[env:planter]
board = esp32doit-devkit-v1
framework = arduino
platform = espressif32
platform_packages =
${esp32.platform_packages}
build_flags =
${common.build_flags}
build_unflags =
${common.build_unflags}
and an empty sketch
#include <Arduino.h>
void setup() {
}
void loop() {
}
(For reproduction, use platformio, initalize a new project with pio init -b esp32doit-devkit-v1, then overwrite the contents of the platformio.ini and create a src/main.cpp file with the given content).
Compiling it fails with internal errors related to PThread / mutexes and some other GCC internals:
Compiling .pio\build\planter\FrameworkArduino\esp32-hal-ledc.c.o
Compiling .pio\build\planter\FrameworkArduino\esp32-hal-matrix.c.o
In file included from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr.h:151,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\ext\atomicity.h:35,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\bits\basic_string.h:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\string:52,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\stdexcept:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\array:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\tuple:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\functional:54,
from C:\Users\Maxi\.platformio\packages\framework-arduinoespressif32@src-537c58760dafe7fcc8a1d9bbcf00b6f6\cores\esp32\FunctionalInterrupt.h:11,
from C:\Users\Maxi\.platformio\packages\framework-arduinoespressif32@src-537c58760dafe7fcc8a1d9bbcf00b6f6\cores\esp32\FunctionalInterrupt.cpp:8:
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr-default.h: In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const __gthread_time_t*)':
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr-default.h:783:12: error: 'pthread_mutex_timedlock' was not declared in this scope
return __gthrw_(pthread_mutex_timedlock) (__mutex, __abs_timeout);
^~~~~~~~
In file included from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr.h:151,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\ext\atomicity.h:35,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\memory:73,
from C:\Users\Maxi\.platformio\packages\framework-arduinoespressif32@src-537c58760dafe7fcc8a1d9bbcf00b6f6\cores\esp32\Esp.cpp:25:
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr-default.h: In function 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const __gthread_time_t*)':
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr-default.h:783:12: error: 'pthread_mutex_timedlock' was not declared in this scope
return __gthrw_(pthread_mutex_timedlock) (__mutex, __abs_timeout);
^~~~~~~~
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr-default.h:783:12: note: suggested alternative: 'pthread_mutex_trylock'
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\xtensa-esp32-elf\no-rtti\bits\gthr-default.h:783:12: note: suggested alternative: 'pthread_mutex_trylock'
Compiling .pio\build\planter\FrameworkArduino\esp32-hal-misc.c.o
In file included from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\cstdlib:75,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\ext\string_conversions.h:41,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\bits\basic_string.h:6391,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\string:52,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\stdexcept:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\array:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\tuple:39,
from c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\include\c++\8.2.0\functional:54,
from C:\Users\Maxi\.platformio\packages\framework-arduinoespressif32@src-537c58760dafe7fcc8a1d9bbcf00b6f6\cores\esp32\FunctionalInterrupt.h:11,
from C:\Users\Maxi\.platformio\packages\framework-arduinoespressif32@src-537c58760dafe7fcc8a1d9bbcf00b6f6\cores\esp32\FunctionalInterrupt.cpp:8:
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\sys-include\stdlib.h: At global scope:
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\sys-include\stdlib.h:155:44: error: expected initializer before '__result_use_check'
void *reallocarray(void *, size_t, size_t) __result_use_check __alloc_size(2)
^~~~~~~~~~~~~~~~~~
c:\users\maxi\.platformio\packages\toolchain-xtensa32\xtensa-esp32-elf\sys-include\stdlib.h:340:52: error: expected initializer before '__alloc_align'
void * aligned_alloc(size_t, size_t) __malloc_like __alloc_align(1)
^~~~~~~~~~~~~
These errors were also independently reported in https://github.com/espressif/esp-at/issues/215, however the proposed solution was to again downgrade to 5.2.0, which doesn't have the C++17 features (as it's announced by @igrr in https://www.esp32.com/viewtopic.php?t=7400).
So I'm not really sure why #include <functional> from FunctionalInterrupt.cpp and even #include <stdlib.h> as shown above produce these errors. If not even these work, how could ESP-IDF be using this toolchain o_O?
Is this error reproducable for you?
Are you trying to do this with the 1.0.4 release version of arduino-esp32? It is not designed for gcc 8.2. There is a branch now built on IDF 4.0, which will require the newer gcc. If you build from that, you should be able to use C++17 extensions (or at least get to a point where there's only a couple issues with it).
@lbernstone thank you very much! By adapting the platformio.ini to use the right branch
[esp32]
; upgrade XTensa32 GCC/G++ compiler to 8.2.0
; use bleeding edge arduino-esp32
platform_packages =
toolchain-xtensa32 @ 2.80200.200226
framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#idf-release/v4.0
The firmware (empty sketch) compiles succesfully. Otherwise the default branch of this repository is master which apprently isn't the one which uses the updated toolchain. It also compiles an example with the new C++17 feature.
Closing issue.
I think there may still be one or two small bits that aren't fully working with the IDF4.0 yet. me-no-dev was also using the version jump as an opportunity to rewrite some of the ancient code that pre-dated the full IDF.
Most helpful comment
I think there may still be one or two small bits that aren't fully working with the IDF4.0 yet. me-no-dev was also using the version jump as an opportunity to rewrite some of the ancient code that pre-dated the full IDF.