xtensa doesn't seem supported yet by crossdev, typically: sudo crossdev xtensa-esp32-elf (...) !!! WARNING - Cannot auto-configure CHOST xtensa-esp32-elf; !!! You should edit !!! by hand to complete your configuration. !!! No LIBC is known for this target. !!! No KERNEL is known for this target. * Log: /var/log/portage/cross-xtensa-esp32-elf-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-xtensa-esp32-elf-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-xtensa-esp32-elf-newlib.log * Emerging cross-newlib ... * error: newlib failed :( * The newlib error is: *** Newlib does not support CPU xtensa
rumors say we have ancient newlib in the tree. Do you know if 3.0.0 supports xtensa? Or maybe you don't need libc at all, then 'crossdev -s1' would do.
(In reply to Sergei Trofimovich from comment #1) > rumors say we have ancient newlib in the tree. Do you know if 3.0.0 supports > xtensa? Or maybe you don't need libc at all, then 'crossdev -s1' would do. I had a look at newlib and don't believe it supports newlib as a libc for xtensa upstream. What do people use for it?
I'm not sure about what people use, and i'm not even sure i need newlib, but the way crossdev works is that it does * gcc stage 1 * <some libc> * gcc stage >1 And as a result i can't get a 'real' gcc because of the 'newlib' error. According to what I see in tar.gz, newlib 2.2.0 doesn't have much for xtensa (only few lines in config.sub/config.guess), but newlib 2.5.0 has a lot more (include/xtensa*, include/elf/xtensa.h, include/Changelog...) So maybe crossdev should use newlib 2.5.0 for xtensa ??
(In reply to Thomas Capricelli from comment #3) > I'm not sure about what people use, and i'm not even sure i need newlib but > the way crossdev works is that it does > > * gcc stage 1 > * <some libc> > * gcc stage >1 > > And as a result i can't get a 'real' gcc because of the 'newlib' error. gcc stage1 is a real gcc. It just does not know any libc-specific stuff, like start files or dynamic loader implementation (which normally does not exist on bare metal). What do you plan to compile with such a toolchain? Maybe we can infer libc from the use case. > So maybe crossdev should use newlib 2.5.0 for xtensa ?? crossdev already does use newlib-2.5.0 (untill you pass -S which uses stable 2.2.0) and 2.5.0 fails the same.
By 'real' i mean a stage4 (with c++). The most obvious need for such a toolchain is to use the official SDK from espressif : https://docs.espressif.com/projects/esp-idf/en/latest/get-started-cmake/linux-setup.html Is uses/requires g++
for the record, esp-idf uses newlib
(In reply to Thomas Capricelli from comment #6) > for the record, esp-idf uses newlib Which version? Is it an upstream newlib? So far I found no versions that can compile for this target.
They have a copy of newlib in their sdk under components/newlib/, i assume it's heavily patched. In .gitmodules, they have: [submodule "newlib_xtensa-2.2.0"] path = newlib_xtensa-2.2.0 url = ssh://git@gitlab.espressif.cn:27227/igrokhotkov/newlib_xtensa-2.2.0.git ignore = dirty The file include/newlib.h contains: #define _NEWLIB_VERSION "2.2.0" The only file with xtensa in the path is ./include/xtensa/config/core-isa.h which is included from include/sys/config.h Otherwise few (12) files have rather minor xtensa specific code.
I figured out how to install xtensa's newlib with crossdev: I edited sys-libs/newlib-9999 ebuild to clone right newlib repo and removed patch from ebuild. After that I run: >crossdev --libc 9999 -s4 xtensa-esp32-elf and it worked, but Arduino IDE gives me this error when I'm trying to use it: >In file included from /home/lekto/Arduino/hardware/espressif/esp32/tools/sdk/esp32/include/freertos/include/freertos/portable.h:52, > from /home/lekto/Arduino/hardware/espressif/esp32/tools/sdk/esp32/include/freertos/include/freertos/FreeRTOS.h:64, > from /home/lekto/Arduino/hardware/espressif/esp32/cores/esp32/Arduino.h:33, > from /tmp/arduino_build_153247/sketch/sketch_aug17a.ino.cpp:1: >/home/lekto/Arduino/hardware/espressif/esp32/tools/sdk/esp32/include/freertos/port/xtensa/include/freertos/portmacro.h:329:15: error: expected constructor, destructor, or type conversion before ‘(’ token > 329 | _Static_assert(portGET_ARGUMENT_COUNT() == 0, "portGET_ARGUMENT_COUNT() result does not match for 0 arguments"); > | ^ >/home/lekto/Arduino/hardware/espressif/esp32/tools/sdk/esp32/include/freertos/port/xtensa/include/freertos/portmacro.h:330:15: error: expected constructor, destructor, or type conversion before ‘(’ token > 330 | _Static_assert(portGET_ARGUMENT_COUNT(1) == 1, "portGET_ARGUMENT_COUNT() result does not match for 1 argument"); > | ^ >exit status 1 Tested with gcc 8.5.0, 9.4.0, 10.3.0, 11.2.0 and I'm getting same error message.
crossdev's automatic handling of xtensa tuples is working as expected. there is no Gentoo port to xtensa, so we have to try and extrapolate values. whether xtensa is working in various packages is a matter for those packages. binutils seems fine. gcc too. if newlib is deficient, then please take it up with the newlib folks (upstream). if you want to point to a fork of newlib, write such an ebuild and use the --lpkg option. based on the error, it does indeed look like a newlib problem: > *** Newlib does not support CPU xtensa i guess you could request that we carry the xtensa-specific patches for newlib, or ship a forked newlib-xtensa package, but i don't think there's any real appetite for that on the developer side. if you wanted to volunteer to be a proxy maintainer for one, then maybe you could get that merged.
