New project wizard fails to initialize project


I am trying to make the switch from arduino-based developement to platformio-based development.
My computer is running ubuntu:

$ uname -a
Linux precision 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

VS and platformio installed without a hitch. As I am completely new to the platformio IDE,
I tried to follow the startup guide to get used to the new tool set.
So, using the Project Wizard, I tried to make a new “blink” application for my ESPduino-32 board.
The initialization fails with a rather interesting error message (as copied straight from the error window):

PIO Core Call Error: “The current working directory /home/ej/ej/output/pio/blink will be used for the project.\n\nThe next files/directories have been created in /home/ej/ej/output/pio/blink\ninclude - Put project header files here\nlib - Put here project specific (private) libraries\nsrc - Put project source files here\nplatformio.ini - Project Configuration File\nResolving esp32doit-espduino dependencies…\nAlready up-to-date.\nUpdating metadata for the vscode IDE…\n\n\nError: Processing esp32doit-espduino (platform: espressif32; board: esp32doit-espduino; framework: espidf)\n--------------------------------------------------------------------------------\nVerbose mode can be enabled via -v, --verbose option\nCONFIGURATION:\nPLATFORM: Espressif 32 (5.2.0) > DOIT ESPduino32\nHARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash\nDEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)\nPACKAGES: \n - framework-espidf @ 3.40402.0 (4.4.2) \n - tool-cmake @ 3.16.4 \n - tool-esptoolpy @ 1.40201.0 (4.2.1) \n - tool-ninja @ 1.7.1 \n - toolchain-esp32ulp @ 1.22851.191205 (2.28.51) \n - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3\nReading CMake configuration…\n– Found Git: /usr/bin/git (found version "2.34.1") \n– The C compiler identification is unknown\n– The CXX compiler identification is unknown\n– The ASM compiler identification is GNU\n– Found assembler: /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc\n– Check for working C compiler: /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc\n– Check for working C compiler: /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc – broken\n– Configuring incomplete, errors occurred!\nSee also "/home/ej/ej/output/pio/blink/.pio/build/esp32doit-espduino/CMakeFiles/CMakeOutput.log".\nSee also "/home/ej/ej/output/pio/blink/.pio/build/esp32doit-espduino/CMakeFiles/CMakeError.log".\n\nfatal: not a git repository (or any of the parent directories): .git\nCMake Error at /home/ej/.platformio/packages/tool-cmake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):\n The C compiler\n\n "/home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc"\n\n is not able to compile a simple test program.\n\n It fails with the following output:\n\n Change Dir: /home/ej/ej/output/pio/blink/.pio/build/esp32doit-espduino/CMakeFiles/CMakeTmp\n \n Run Build Command(s):/home/ej/.platformio/packages/tool-ninja/ninja cmTC_1acab && [1/2] Building C object CMakeFiles/cmTC_1acab.dir/testCCompiler.c.obj\n FAILED: CMakeFiles/cmTC_1acab.dir/testCCompiler.c.obj \n /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -mlongcalls -Wno-frame-address -o CMakeFiles/cmTC_1acab.dir/testCCompiler.c.obj -c testCCompiler.c\n /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/…/libexec/gcc/xtensa-esp32-elf/8.4.0/cc1: /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/ version `GLIBCXX_3.4.15’ not found (required by /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/…/libexec/gcc/xtensa-esp32-elf/8.4.0/cc1)\n ninja: build stopped: subcommand failed.\n \n \n\n \n\n CMake will not be able to correctly generate this project.\nCall Stack (most recent call first):\n /home/ej/.platformio/packages/framework-espidf/tools/cmake/project.cmake:296 (__project)\n CMakeLists.txt:3 (project)\n\n\n\n========================== [FAILED] Took 1.25 seconds ==========================”

It would seem that somehow there is a cash between on one hand
what the Project Wizard expects to find and on the other hand the presence
of the Xilinx tool chain in /opt on my computer.

What is going on here, where is the wizard failing, and how do I resolve this failure?

With many thanks in advance,

EJ (Evert-Jan Pol)

Well that’s weird, what does

ldd /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc


$ ldd /home/ej/.platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc (0x00007fffde3f5000) => /lib/x86_64-linux-gnu/ (0x00007f987f21c000) => /lib/x86_64-linux-gnu/ (0x00007f987f135000) => /lib/x86_64-linux-gnu/ (0x00007f987ef0d000)
/lib64/ (0x00007f987f466000) => /lib/x86_64-linux-gnu/ (0x00007f987eeed000)

And thank you for this quick response!!

Hm, I’m not sure why

is the file that the dependency of xtensa-esp32-elf-gcc resolves to…

Is /lib/x86_64-linux-gnu/ a symlink to the Xilinx version? What’s the output of

ls -l /lib/x86_64-linux-gnu/

$ ls -l /lib/x86_64-linux-gnu/
lrwxrwxrwx 1 root root 19 May 13 13:11 /lib/x86_64-linux-gnu/ →

That looks like it’s its own seperate file, so ls -l /lib/x86_64-linux-gnu/ does not show a symlink anymore?

As a sanity check, when you move the Xilinx version out of the way, it works normally?

cd /home/ej/ej/output/pio/blink
mv /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/ /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.backup
~/.platformio/penv/bin/pio run
mv /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/libstdc++.backup /opt/Xilinx/14.7/ISE_DS/ISE/lib/lin64/

Hi max, again thanks for looking into this!
Checked the std c library to be sure:

$ ls -l /lib/x86_64-linux-gnu/
-rw-r–r-- 1 root root 2252096 May 13 13:11 /lib/x86_64-linux-gnu/

So it is indeed a regular file, not a link.
Temporarily moving the xilinx lib out of the way does help!
The last bit of the run output (the entire blurb is very large) is:

Archiving .pio/build/esp32doit-espduino/bootloader/esp-idf/micro-ecc/libmicro-ecc.a
Indexing .pio/build/esp32doit-espduino/bootloader/esp-idf/micro-ecc/libmicro-ecc.a
Linking .pio/build/esp32doit-espduino/bootloader.elf
Building .pio/build/esp32doit-espduino/bootloader.bin v4.2.1
Creating esp32 image…
Merged 1 ELF section
Successfully created esp32 image.
Linking .pio/build/esp32doit-espduino/firmware.elf
Retrieving maximum program size .pio/build/esp32doit-espduino/firmware.elf
Checking size .pio/build/esp32doit-espduino/firmware.elf
Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
RAM: [ ] 3.5% (used 11312 bytes from 327680 bytes)
Flash: [== ] 16.1% (used 169229 bytes from 1048576 bytes)
Building .pio/build/esp32doit-espduino/firmware.bin v4.2.1
Creating esp32 image…
Merged 2 ELF sections
Successfully created esp32 image.
========================= [SUCCESS] Took 36.74 seconds =========================

Okay, now that the Xilinx version should be back from the last mv command, regular building is broken again? (pio run -t clean, pio run)

Then what’s the output of

pio pkg exec -p toolchain-xtensa-esp32 -c "xtensa-esp32-elf-gcc --version"


Hmmm… The command

~/.platformio/penv/bin/pio run

now returns success, but it doesn’t need to compile anything. (the output is rather short!)
So, how can I do a clean?

With ~/.platformio/penv/bin/pio run -t clean (“target: clean”)

Ok, this is definitely weird… With the Xilinx lib back in place (second mv command)
the run command now returns succes! :thinking:

And, by the way, here is the output of the pkg command:

$ ~/.platformio/penv/bin/pio pkg exec -p toolchain-xtensa-esp32 -c “xtensa-esp32-elf-gcc --version”
Using toolchain-xtensa-esp32@8.4.0+2021r2-patch3 package
xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2-patch3) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

Sorry, i need to sign off for an hour or two, back later!

Maybe it has always been working on the commandline. Does it still work in the VSCode IDE when you clean + build the project there, with the Xilinx file moved back to its original place?

Ok, that is indeed something worth checking!

-Verified that the xilinx lib file is back in place
-did the clean on the cli as before, just to be sure
-removed the project by hand from my pio workspace
-started the new project wizard in the gui

In the first try, I forgot to change the platform, so the choice was Arduino.
That run completed successfully.

Discovering my omission, I removed again the project directory,
and ran the new project wizard again.
This run produced the same error, again listing the Xilinx std lib.

Hey Max, I’ve done a few experiments, and the common denominator
between all results is that indeed project setup via the gui never works,
and project setup via the cli always works!

Open a PlatformIO CLI within VSCode and execute

pio pkg exec -p toolchain-xtensa-esp32 -c "ldd xtensa-esp32-elf-gcc"
pio pkg exec -p toolchain-xtensa-esp32 -c "xtensa-esp32-elf-gcc --version"

what does it show?

Hi Max, sorry I could not answer you yesterday, there seems to be a limit
on the number of messages that I can post in a single day…
And a “day” is 24 hours, so even earlier this morning I was not allowed to post!
I could not even let you know that I was blocked…:frowning:

Answers to your two questions:

$ pio pkg exec -p toolchain-xtensa-esp32 -c “ldd xtensa-esp32-elf-gcc”
Using toolchain-xtensa-esp32@8.4.0+2021r2-patch3 package
ldd: ./xtensa-esp32-elf-gcc: No such file or directory

$ pio pkg exec -p toolchain-xtensa-esp32 -c “xtensa-esp32-elf-gcc --version”
Using toolchain-xtensa-esp32@8.4.0+2021r2-patch3 package
xtensa-esp32-elf-gcc (crosstool-NG esp-2021r2-patch3) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO

Do you have any Xilinx-related extensions installed in VSCode? Do you see if the installation did any modifications, e.g. for $PATH, in ~/.profile, ~/.bashrc or related files?