Compile fails on ARMv6 RPi

[ThorpeJosh]

Bug Report

Current behavior

$ arduino-cli compile -v --verify --upload -p /dev/ttyUSB0 -b arduino:avr:uno path_to_script/GateSketch
Using board 'uno' from platform in folder: /root/.arduino15/packages/arduino/hardware/avr/1.8.3
Using core 'arduino' from platform in folder: /root/.arduino15/packages/arduino/hardware/avr/1.8.3
Detecting libraries used...
/root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10607 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I/root/.arduino15/packages/arduino/hardware/avr/1.8.3/cores/arduino -I/root/.arduino15/packages/arduino/hardware/avr/1.8.3/variants/standard /tmp/arduino-sketch-2C02EEF97571C887912CB7C968D29AB0/sketch/GateSketch.ino.cpp -o /dev/null

Error during build: fork/exec /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++: no such file or directory

Expected behavior

No library errors

Environment

arduino-cli alpha Version: 0.16.1 Commit: 76f5549 Date: 2021-02-25T10:43:25Z

• OS and platform:
  Raspberry Pi Model B, Raspbian Buster.

Additional context

I run this arduino compilation in a debian:buster-slim docker container.
No issues on newer Rpi's running ARMv7, and no issues if compiling on ARMv6 host. Only fails when compiling in a docker container on an ARMv6 RPi.

The file it claims does not exist, does exist.

ls -lah /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++
-rwxr-xr-x 2 root root 743K Mar  4 09:24 /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++

[matthijskooijman]

The file it claims does not exist, does exist.

I think (memory is a bit vauge) this same (and confusing) error message also occurs when there is a mismatch in architecture (i.e. 32bit vs 64bit) for a binary, or when a library needed by the binary is not available (or not in the right architecture).

Could you run these three commands and show us the output?

uname -a
file /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++
ldd /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++

edit: Added one extra command

[ThorpeJosh]

Hi,

# uname -a
Linux 8b28ba6b2802 5.10.14+ arduino/arduino-cli#1401 Mon Feb 8 14:19:47 GMT 2021 armv6l GNU/Linux
# file /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++
/root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, stripped
# ldd /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++
not a dynamic executable

I have a working instance of arduino-cli and the output is different only on the ldd command (obviously).

cheers,

[matthijskooijman]

Output looks ok, except "not a dynamic executable" seems unexpected, especially since the file command says it is a dynamic executable. But the command is ARMv5 and your kernel is ARMv6, so that should work, also everything 32-bit AFAICS.

One other command to try:

strace -f /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++

This might need you to install the strace package first. This command should show all the syscalls done by an executable, I hope it shows which (library) file is triggering the No such file or directory exactly.

[ThorpeJosh]

# strace -f /root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++
execve("/root/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++", ["/root/.arduino15/packages/arduin"...], 0xbeb1be14 /* 8 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++```

[ThorpeJosh]

I think it has truncated the file in the output?

[matthijskooijman]

Hm, this strace does not really help, since it's the exec call that fails, so I can't see what happens behind the scenes for this exec call. I don't have any more ideas just now, maybe @facchinm has some experience with the Rpi build?

[ThorpeJosh]

Update: Compliation works on older RPi (armv6l) when arduino-sli is installed on the host OS. It fails only when arduino-cli is installed and run in a docker container.

However, on a newer RPi (armv7l) arduino-cli compiles on host OS and in a docker container without issues.

What is the difference between a docker container on an armv6 and armv7 host?

[umbynos]

Hi @ThorpeJosh, sorry for the delay in the response...
Could you please try with the latest version of the CLI?

If the problem still exists, could you please the docker configuration you have used?

[nuno-silva]

Hi! Not sure if this is actually the same exact problem, but I was getting this error on a Raspberry Pi 3 B (ARMv7):

$ arduino-cli compile --fqbn esp32:esp32:esp32 



Used platform Version Path                                                        
esp32:esp32   2.0.6   /home/arduino/.arduino15/packages/esp32/hardware/esp32/2.0.6

Error during build: fork/exec /home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++: no such file or directory

The file does exist:

$ file /home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++
/home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=d80d264c42b092c58ad16f1f1f454d13664e109a, stripped

But I am unable to run it (hence the confusing message from arduino-cli):

$ /home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++
-bash: /home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++: No such file or directory

$ strace /home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++
execve("/home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++", ["/home/arduino/.arduino15/package"...], 0x7eb82070 /* 32 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++

---

Some more system info:

$ arduino-cli version
arduino-cli  Version: 0.29.0 Commit: 76251df9 Date: 2022-11-17T09:21:45Z

$ arduino-cli core list
ID          Installed Latest Name 
esp32:esp32 2.0.6     2.0.6  esp32

$ uname -a
Linux pi3 5.10.63-v7+ arduino/arduino-cli#1459 SMP Wed Oct 6 16:41:10 BST 2021 armv7l ARMv7 Processor rev 4 (v7l) BCM2835 GNU/Linux
$ cat /proc/cpuinfo | head -n 10
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 70.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

Upon further investigation, I noticed I'm missing the /lib/ld-linux.so.3 interpreter needed by the binary.

Maybe not the ideal solution, but I fixed this by symlinking the missing interpreter:

$ sudo ln -s  /lib/ld-linux-armhf.so.3  /lib/ld-linux.so.3

$ /home/arduino/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2-patch5/bin/xtensa-esp32-elf-g++       
xtensa-esp32-elf-g++: fatal error: no input files
compilation terminated.

[umbynos]

@nuno-silva does this happen also with the arduino:avr core? Like reported in the original issue?

[nuno-silva]

hey @umbynos ! I don't have access to the Raspberry pi now but I'll give it a try next week and report back.

[nuno-silva]

hey @umbynos, sorry for the delay. I deleted the symlink and tested using arduino:avr core.

Using

• arduino:[email protected]
• arduino:[email protected]
• arduino:[email protected]
• arduino:[email protected]

An empty sketch compiles with no problem:

~/Arduino/Example $ arduino-cli compile --fqbn arduino:avr:uno
Sketch uses 444 bytes (1%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.


Used platform Version Path                                                        
arduino:avr   1.8.6   /home/arduino/.arduino15/packages/arduino/hardware/avr/1.8.6

Note avr-gcc in this case seems to be using the correct interpreter:

$ file .arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-gcc          
.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-gcc: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, stripped

[orhun]

Got this on Raspberry Pi 3 Model B Rev 1.2 running Alpine Linux v3.17 aarch64 and it was due to Arduino tools using glibc:

$ file /home/orhun/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++

/home/orhun/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=fc933c0814da959514cf03a2e47f58905aadb382, stripped

$ ldd /home/orhun/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++
	/lib/ld-linux-aarch64.so.1 (0x7fb6ff7000)
	libc.so.6 => /lib/ld-linux-aarch64.so.1 (0x7fb6ff7000)
Error loading shared library ld-linux-aarch64.so.1: No such file or directory (needed by /home/orhun/.arduino15/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino7/bin/avr-g++)

It is solved by installing the glibc compatibility package:

$ apk add gcompat

Just my 2 cents.

[ChillarAnand]

Same issue is happening on ARMv7 RPi as well. arduino/ctags#19