arm-none-eabi-g++: error trying to exec 'cc1plus': execvp: No such file or directory
Just create a new project, immediately try to build, and it does that:
As you can see, main.cpp is unmodified, as is platformio.ini:
; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html
[env:teensy41]
platform = teensy
board = teensy41
framework = arduino
I also have the official standalone Arduino IDE installed (yuck!), and it works just fine.
Arduino IDE v1.8.19
VSCode v1.76.0
PIO IDE v3.1.1
Just checked manually: no updates available.
That doesn’t look good at all.
What’s the output of
~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
?
Does deleting the toolchain-gccarmnoneeabi folder and rebiulding the project make a difference?
aaron@Aaron-Bench:~ $ ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2019-q1-update) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
aaron@Aaron-Bench:~ $
There a bunch of stuff in ~/.platformio/packages/:
I sent that one to trash, in case I need to bring it back, and then started VSCode. No change.
I sent the other one to trash too, and then the build did this:
And I got this weirdness:
aaron@Aaron-Bench:~ $ ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
bash: /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++: No such file or directory
aaron@Aaron-Bench:~ $ ls ~/.platformio/packages
contrib-piohome framework-arduinoespressif32@3.10006.210326 toolchain-atmelavr toolchain-xtensa32 tool-cppcheck tool-esptoolpy@1.30100.210531 tool-mklittlefs tool-scons
framework-arduinoespressif32 framework-arduinoteensy toolchain-gccarmnoneeabi toolchain-xtensa-esp32 tool-esptoolpy tool-mkfatfs tool-mkspiffs tool-teensy
aaron@Aaron-Bench:~ $ ls ~/.platformio/packages/toolchain-gccarmnoneeabi/
arm-none-eabi bin lib package.json share
aaron@Aaron-Bench:~ $ ls ~/.platformio/packages/toolchain-gccarmnoneeabi/bin
arm-none-eabi-addr2line arm-none-eabi-c++ arm-none-eabi-cpp arm-none-eabi-gcc arm-none-eabi-gcc-ar arm-none-eabi-gcc-ranlib arm-none-eabi-ld arm-none-eabi-objcopy arm-none-eabi-size
arm-none-eabi-as arm-none-eabi-c++filt arm-none-eabi-g++ arm-none-eabi-gcc-5.4.1 arm-none-eabi-gcc-nm arm-none-eabi-gdb arm-none-eabi-ld.bfd arm-none-eabi-objdump
aaron@Aaron-Bench:~ $ ls ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
/home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
aaron@Aaron-Bench:~ $ ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
bash: /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++: No such file or directory
aaron@Aaron-Bench:~ $ sudo ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
[sudo] password for aaron:
sudo: unable to execute /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++: No such file or directory
aaron@Aaron-Bench:~ $ ls -l ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
-rwxr-xr-x 1 aaron aaron 800832 Dec 31 1969 /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
aaron@Aaron-Bench:~ $
Stuff like that can happen when you have a binary incompatibility between the target program and your operating system or CPU.
What is the output of
lsb_release -a
uname -a
ldd /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
aaron@Aaron-Bench:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
aaron@Aaron-Bench:~ $ uname -a
Linux Aaron-Bench 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux
aaron@Aaron-Bench:~ $ ldd /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
not a dynamic executable
aaron@Aaron-Bench:~ $
The 64-bit version of Raspbian has only been out of beta for a couple of weeks now, and I installed this long before that. I update it regularly, with sudo apt {update|full-upgrade|autoremove}, and often finds some.
I don’t do beta unless it’s all that’s available in any form, and really don’t like things that have just come out of beta either, which is where Raspbian is at the moment. A small group of beta testers is not going to find everything…
So this really is a well-supported 32-bit desktop OS in 2023. If that’s the problem, then I think it was premature to drop 32-bit support for this…and anything else really, that runs on Linux.
Hm, go figure. Let’s check what “interpreter” the .elf file then needs, i.e., where it thinks the system’s main loader is vs what the reality is on your system.
Execute
readelf -l ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ | grep 'Requesting'
what’s the output? It should output something like
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
then check whether that file exists or not.
Also compare that against which interperter a standard program on your system wants, like cat:
readelf -l $(which cat) | grep 'Requesting'
aaron@Aaron-Bench:~ $ readelf -l ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ | grep 'Requesting'
[Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
aaron@Aaron-Bench:~ $ readelf -l $(which cat) | grep 'Requesting'
[Requesting program interpreter: /lib/ld-linux-armhf.so.3]
aaron@Aaron-Bench:~ $
The frick is going on here. That’s the latest 64-bit Raspbian release but they changed the interpreter name?
Can you please point to the exact download link for the Raspbian you’ve installed?
That may be a stupid try, but can the armhf loader load the aarch64 binary?
/lib/ld-linux-armhf.so.3 ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
I’m pretty sure it’s 32-bit. Like I said, the official 64-bit Raspbian is only just out of beta, and this certainly isn’t that! It might mis-report itself, though I’m not sure why. Maybe it has something to do with the ARM extension that it uses to make 8GB of physical RAM usable? (each process still has a 3GB cap)
I guess if it is mis-reporting itself, that could trick PIO into installing the wrong version, which then fails.
This SD card was part of a “getting started” kit from Amazon with NOOBS pre-installed. (shortly after I bought it, NOOBS was replaced with something else) I figured I’d try that instead of the RPi imager that I’d been using for other projects, and I really liked how it turned out! Slightly different set of apps (though not by much), and it asked to create a user account other than the default ‘pi’. (YES, please do that!)
aaron@Aaron-Bench:~ $ /lib/ld-linux-armhf.so.3 ~/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --version
/home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++: error while loading shared libraries: /home/aaron/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++: wrong ELF class: ELFCLASS64
aaron@Aaron-Bench:~ $
Well that would be very fatal for PlatformIO if it really is internally 32-bit but reports via sys.platform (Python) as aarch64, which is what PlatformIO believes.
Please download the 32-bit version (armv8l for a Pi 4 I guess) by doing
wget https://dl.registry.platformio.org/download/platformio/tool/toolchain-gccarmnoneeabi/1.50401.190816/toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz
tar xfv toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz
./toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816/bin/arm-none-eabi-gcc --version
A different Pi 4 says:
aaron@Aaron-NotesPC:~ $ uname -a
Linux Aaron-NotesPC 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux
aaron@Aaron-NotesPC:~ $
That OS originally ran on a Pi 3B+, and then I moved the SD card to a 4B+ and kept using it. Come to think of it, I don’t actually have an original image that has only seen a Pi 4.
Then it would definitely by appropriate to take a new SD card and flash it with the latest Raspbian for a Pi 4 and retest.
aaron@Aaron-Bench:~ $ cd Downloads/
aaron@Aaron-Bench:~/Downloads $ wget https://dl.registry.platformio.org/download/platformio/tool/toolchain-gccarmnoneeabi/1.50401.190816/toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz
--2023-03-31 07:47:55-- https://dl.registry.platformio.org/download/platformio/tool/toolchain-gccarmnoneeabi/1.50401.190816/toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz
Resolving dl.registry.platformio.org (dl.registry.platformio.org)... 88.198.170.159
Connecting to dl.registry.platformio.org (dl.registry.platformio.org)|88.198.170.159|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://usc1.contabostorage.com/250040e607e8431abaff8727621872f9:pioregmirrorus/tools/f2/21/6f75060f5dd11faea4800556005d9d77a39c363ff90f540b9d2df87f7ee4/toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz [following]
--2023-03-31 07:47:56-- https://usc1.contabostorage.com/250040e607e8431abaff8727621872f9:pioregmirrorus/tools/f2/21/6f75060f5dd11faea4800556005d9d77a39c363ff90f540b9d2df87f7ee4/toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz
Resolving usc1.contabostorage.com (usc1.contabostorage.com)... 209.126.15.84, 209.126.15.85
Connecting to usc1.contabostorage.com (usc1.contabostorage.com)|209.126.15.84|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 51202454 (49M) [binary/octet-stream]
Saving to: ‘toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz’
toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz 100%[========================================================================================================================================>] 48.83M 915KB/s in 65s
2023-03-31 07:49:01 (772 KB/s) - ‘toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz’ saved [51202454/51202454]
aaron@Aaron-Bench:~/Downloads $ tar xfv toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816.tar.gz
arm-none-eabi/bin/ar
arm-none-eabi/bin/as
arm-none-eabi/bin/ld
arm-none-eabi/bin/ld.bfd
arm-none-eabi/bin/nm
arm-none-eabi/bin/objcopy
arm-none-eabi/bin/objdump
...
aaron@Aaron-Bench:~/Downloads $ ./toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816/bin/arm-none-eabi-gcc --version
bash: ./toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816/bin/arm-none-eabi-gcc: No such file or directory
aaron@Aaron-Bench:~/Downloads $
What?!
D’oh! No containing folder. Fixed that:
aaron@Aaron-Bench:~/Downloads $ ./toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816/bin/arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
aaron@Aaron-Bench:~/Downloads $
So the 32-bit compiled version does work. While you could now manually do a cp -r toolchain-gccarmnoneeabi-linux_armv6l-1.50401.190816/* ~/.platformio/packages/toolchain-gccarmnoneeabi to replace the AArch64 binaries that PlatformIO downloaded for you (which you would also need for teensy upload etc), I think it’s really more important to cleanly reinstall Raspbian on that Pi so that PlatformIO hopefully recognizes the system architecture as aarch64 or armv7l correctly. The system seems to be in a very weird state right now.
I was thinking the same thing…except I have a bunch of other stuff that took a while to set up, and I’m not looking forward to doing that again.
But if I don’t, I’ll probably have the same problem with something else too…or maybe PIO again if it decides to update or “fix my broken install”.
I do have a spare card, so I guess it wouldn’t hurt to pull this one and keep it as a backup, and start from “official scratch”. Good thing my weekend is free. :-/
Well, I took a risk on the freshly-released 64-bit version of RPi OS, as downloaded by the official Raspberry Pi Imager.
It’s a bit slower: often seems to do nothing for about 10 seconds while the native CPU load history continues scrolling and shows barely anything, then pegs to 100% for another 10 seconds or so, and finally copies the 2-byte text file via the GUI. That’s gotta be a software bug in RPi OS itself.
Anyway, I managed to get most of my tools re-installed and tested on that - I’ll find out soon enough what I’m still missing - and tried to create and build a new VSCode+PIO project again. This time it worked! Then I tried to upload, and it couldn’t find the Teensy.
Turns out that PJRC has a set of udev rules that need to be applied to Linux, and whatever installer I used before, did that automatically. This one didn’t. Ran the command to copy their file to where Linux looks for those things, and that works too now.
Blinky LED + USB Serial + UART, finally working as a PIO project!
(and I didn’t bother to reinstall the Arduino IDE)
Thanks for your help!
For completeness’ sake: PlatformIO also has udev rules, maybe if you didn’t install those, that was the error.
https://docs.platformio.org/en/latest/core/installation/udev-rules.html#platformio-udev-rules
Like I said, that was only a momentary second problem, and was solved quickly.
PJRC’s rules work just fine, but of course they’re only for the Teensy, whereas the PIO rules are for a bunch of things. I’ve got both now, with the PIO version taking priority (99- over 00-), and I can build and load on a Teensy 4.1 either way.
