lang/gcc12 is at this moment the standard gcc compiler for ports for non-PowerPC architectures (see Mk/bsd.default-versions.mk). Is it possible to let gcc12 compile this port by default at least for 13-STABLE/CURRENT?
The port is locked to gcc10 because the last time I tried gcc11 it failed to build. I just retested with 11 and 12: gcc11: [INFO ] Installing pass-2 core C gcc compiler [ERROR] /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-97-gc752ad5/.build/src/gcc-5.2.0/gcc/reload1.c:115:24: error: use of an operand of type 'bool' in 'operator++' is forbidden in C++17 gcc12: [INFO ] Installing pass-2 core C gcc compiler [ERROR] /wrkdirs/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-97-gc752ad5/.build/src/gcc-5.2.0/gcc/reload1.c:115:24: error: use of an operand of type 'bool' in 'operator++' is forbidden in C++17 Is there a way to disable this error?
GCC 5, which this seems to be based on, went end of life in 2017 - six years ago. Instead of trying to hack that old codebase updating to a newer version of GCC probably makes more sense. (Note that GCC 5.2 is not even the last in that release series. It is possible, though not likely, that a later GCC 5.x release actually has this addressed.)
My skills of understanding the design of the toolset is limited. I stumbled into this problem regarding gcc, since my CURRENT boxes are on "default gcc", which is lang/gcc (which is lang/gcc12 ). It takes a significant amount of time on my oldish hardware to compile gcc. First: lang/gcc12 (as other compilers) have backward compatibility knobs, like -std=c++11 I tried to apply those knobs via "CXXFLAGS+=-std=c++11" in the Makefile to get rid of the c++17 warning (treated as error) when compiling with gcc12, but no success - I guess the configure part via (gnu) autotools isn't run properly to deploy the CXXFLAGS knob or, more likely, the set of options is fixed in the sources and need to be patched. Second: I did not understand the concept of this port, on the one hand we use gcc10 to compile the "port", on the other hand, gcc5.2 is included as the cross compiler(?) to deliver Xtensa binary code. Reasons unknown. Third: I checked whether the FreeBSD base compiler, LLVM (LLVM16 now in CURRENT) supports the target Xtensa - and it seems, following this https://www.esp32.com/viewtopic.php?t=9226 reveals that LLVM already supports the target in some way - I did not investigate the state of efficiency yet. At the end I'd like to have a development environment ready to compile and deploy some code on ESP32 MCUs.
(In reply to Gerald Pfeifer from comment #2) I do not argue your issue with the age of gcc5. However, I wrote this port in support of a specific project (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3) which is currently tied to an old (and modified) version of esp-idf and it requires this specific version of the ESP32 toolchain. The is currently a serious effort underway to migrate openvehicles to a current esp-idf version. Once a bit more progress is made in that (non-trivial) effort, I will move devel/xtensa-esp32-elf to the corresponding espressif-crosstool-NG toolchain.
(In reply to O. Hartmann from comment #0) Help me understand your initial complaint; is it that you don't want to have to install both gcc10 and gcc12 at the same time? (In reply to O. Hartmann from comment #3) Currently the port uses gcc10 to cross compile a number of tools including gcc 5.2.0 and gdb 7.10. Regarding llvm vs. gcc, I'm happy to use whatever compiler and version espressif selects for each version of the esp-idf via their crosstool-NG package (https://github.com/espressif/crosstool-ng/).
(In reply to Craig Leres from comment #5) My "initial complaint" is not to have several different gcc compiler versions compiling for ports and I'd like to ask whether there is the possibility to switch the ports's compiler from gcc10 to gcc12. From a naive perspective, this seems to be possible. Kind regards