Can't target Raspberry Pi 1 and Pi Zero #426

BrianHoldsworth · 2020-05-22T13:09:19Z

This issue is related to #391 and #414

I am trying to build for the Pi Zero W using target=arm-unknown-linux-gnueabihf. I think that's the right target for RPi, but there is no way to distinguish between building for ARMv6 (RPi 1 and Zero) vs. ARMv7 (RPi 2). The resulting binary is ARMv7, which works on RPi2, but crashes with a segmentation fault on RPi Zero.

I add the following in my simple Rust project's Cross.toml file to avoid using the older "0.2" version docker image that was upgraded for #391

[target.arm-unknown-linux-gnueabihf]
image = "rustembedded/cross:arm-unknown-linux-gnueabihf"

AND I can confirm using docker images after running cross build that I'm not using the older arm-unknown-linux-gnueabihf-0.2.0

REPOSITORY           TAG                           IMAGE ID            CREATED             SIZE
rustembedded/cross   arm-unknown-linux-gnueabihf   ba2dc7364b10        5 days ago          2.2GB

It appears to me that cross build is creating an ARMv7 binary, and this causes the Seqmentation Fault on the Pi Zero, which is an ARMv6 CPU.

$ !readelf
readelf --arch-specific target/arm-unknown-linux-gnueabihf/debug/rpi-test
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_GOT_use: GOT-indirect
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_ABI_FP_16bit_format: IEEE 754

The text was updated successfully, but these errors were encountered:

schlamar · 2020-05-27T19:02:07Z

Yes, the compiler downloaded from developer.arm.com in the Dockerfile (https://github.com/rust-embedded/cross/blob/master/docker/Dockerfile.arm-unknown-linux-gnueabihf#L14) is built with --with-arch=armv7-a (you can check that with arm-linux-gnueabihf-gcc -v). So it cannot target ARMv6.

Here is a possible solution: https://github.com/Pro/raspi-toolchain

schlamar · 2020-05-28T06:33:25Z

I just confirmed that the above toolchain works for Pi Zero.

And the official Raspberry toolchain works, too. Here is a description: japaric/rust-cross#42

BrianHoldsworth · 2020-05-29T02:22:49Z

@schlamar Thanks for the response and I'm aware of those other options. Problem is they aren't suitable for complex projects that need to install native arm packages into the docker image; something that this project manages quite nicely. Case in point my current Rust project builds fine using this project for RPi 2 but cannot link (due to dependency issues) using this alternate approach for RPi Zero. So, I'll continue to pursue support here and/or cobble together a Dockerfile that merges the necessary ARMv6 toolchain support.

schlamar · 2020-05-29T07:18:04Z

Yes, of course :-) The cross maintainers should integrate one of these solutions (or another working alternative for ARMv6) into their arm-unknown-linux-gnueabihf Dockerfile.

But other persons who stumble about this issue by Google (like me two days ago) will be thankful for a workaround I guess ;-)

reitermarkus · 2020-05-29T14:34:37Z

The cross maintainers should integrate one of these solutions

PRs are welcome. 😉

tmigone · 2020-07-31T13:39:44Z

hey @BrianHoldsworth did you find a solution? I think I'm having a similar problem. I'm building a project for the Raspberry Pi Zero and failing to link dependencies even though they are installed.

BrianHoldsworth · 2020-08-03T13:48:46Z

@tmigone I punted for now, since I am just in prototype and can target an RPi2

zenria · 2020-09-20T18:38:29Z

Hi, I've managed to make it work using a custom docker image: https://github.com/zenria/rbp1-cross-docker

BrianHoldsworth · 2020-09-23T16:18:50Z

@zenria I can see how that should work. Unfortunately, something about this Dockerfile seems to revert to a different / older glibc for ARM, which breaks linking for me.

zenria · 2020-09-23T18:22:28Z

@zenria I can see how that should work. Unfortunately, something about this Dockerfile seems to revert to a different / older glibc for ARM, which breaks linking for me.

Which distro do you run on your Pi?

I'm building executables with this docker image that runs successfully on Raspbian 9.11:

Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 9.11 (stretch)
Release:	9.11
Codename:	stretch

BrianHoldsworth · 2020-09-23T18:31:09Z

@zenria I am targeting Arch Linux ARM, a rolling distro, on RPi2 (works fine linking and running with cross build) and PRi Zero (generates armv7 binary when used with normal cross build, and fails on linking with your custom docker image). I do my cross-compiles on x86_64 running Manjaro Linux, which is based on Arch Linux x86.

The main difference between your docker and mine is I have added:

RUN dpkg --add-architecture armhf &&
apt-get update &&
apt-get install --assume-yes pkg-config libudev-dev:armhf

This because I use Rust code that is dependent on libudev.

chaseboren · 2021-02-28T03:59:06Z

I was able to successfully compile for the Pi Zero with this patch that utilizes abhitronix pre-built tool chains. It breaks the toolchain versioning, but GCC 8, 9, and 10 versions are available.

diff --git a/docker/Dockerfile.arm-unknown-linux-gnueabihf b/docker/Dockerfile.arm-unknown-linux-gnueabihf
index 0edd07e..ba0f926 100644
--- a/docker/Dockerfile.arm-unknown-linux-gnueabihf
+++ b/docker/Dockerfile.arm-unknown-linux-gnueabihf
@@ -1,7 +1,9 @@
-FROM ubuntu:18.04
+FROM ubuntu:20.04

COPY common.sh lib.sh /
-RUN /common.sh
+RUN /common.sh
+
+

COPY cmake.sh /
RUN /cmake.sh
@@ -9,12 +11,13 @@ RUN /cmake.sh
COPY xargo.sh /
RUN /xargo.sh

RUN mkdir /usr/arm-linux-gnueabihf \

&& cd /usr/arm-linux-gnueabihf \
&& export TOOLCHAIN_VERSION=8.3-2019.03 \
&& curl --retry 3 -sSfL https://developer.arm.com/-/media/Files/downloads/gnu-a/${TOOLCHAIN_VERSION}/binrel/gcc-arm-${TOOLCHAIN_VERSION}-x86_64-arm-linux-gnueabihf.tar.xz -O \
&& tar --strip-components 1 -xJf gcc-arm-${TOOLCHAIN_VERSION}-x86_64-arm-linux-gnueabihf.tar.xz \
&& rm gcc-arm-${TOOLCHAIN_VERSION}-x86_64-arm-linux-gnueabihf.tar.xz

&& cd /usr/arm-linux-gnueabihf \
&& export TOOLCHAIN_VERSION=10.2-2020.11 \
&& curl --retry 3 -SfL --output tool.tar.gz https://sourceforge.net/projects/raspberry-pi-cross-compilers/files/Raspberry%20Pi%20GCC%20Cross-Compiler%20Toolchains/Buster/GCC%2010.2.0/Raspberry%20Pi%201%2C%20Zero/cross-gcc-10.2.0-pi_0-1.tar.gz/download -O \
&& tar --strip-components 1 -xzf tool.tar.gz \
&& rm tool.tar.gz

ENV PATH /usr/arm-linux-gnueabihf/bin:$PATH

diff --git a/docker/common.sh b/docker/common.sh
index 16396a8..fddfbe0 100755
--- a/docker/common.sh
+++ b/docker/common.sh
@@ -35,4 +35,5 @@ if_centos install_packages
if_ubuntu install_packages
g++
libc6-dev \

pkg-config

pkg-config \
xz-utils

Alexhuszagh · 2022-05-27T16:12:04Z

Rust's official Platform Support says that these targets should be ARMv6, so I would consider this a bug, since these images should target ARMv6 processors.

target notes

arm-unknown-linux-gnueabi ARMv6 Linux (kernel 3.2, glibc 2.17)

arm-unknown-linux-gnueabihf ARMv6 Linux, hardfloat (kernel 3.2, glibc 2.17)

The current toolset uses ARMv7-A.

Change the `arm-unknown-linux-gnueabihf` to build a toolchain using crosstool-ng, so that we build a toolchain using ARMv6 support, rather than ARMv7. This also adds support for crosstool-ng-based images, which are configured from template config files so that we can modify the GCC, glibc, and Linux versions. These are configured by running `crosstool-ng/configure.sh`, which scans that directory for all `*.config.in` files, and configures them to `docker/crosstool-config`. The script can have the toolchain versions modified via `GCC_VERSION`, `GLIBC_VERSION`, and `LINUX_VERSION`. Closes cross-rs#426.

734: Fix ARMv6 HF image to correctly build for ARMv6 architecture. r=Emilgardis a=Alexhuszagh Change the `arm-unknown-linux-gnueabihf` to build a toolchain using crosstool-ng, so that we build a toolchain using ARMv6 support, rather than ARMv7. This also adds support for crosstool-ng-based images, which are configured from template config files so that we can modify the GCC, glibc, and Linux versions. These are configured by running `crosstool-ng/configure.sh`, which scans that directory for all `*.config.in` files, and configures them to `docker/crosstool-config`. The script can have the toolchain versions modified via `GCC_VERSION`, `GLIBC_VERSION`, and `LINUX_VERSION`. Closes #426. 735: add issue templates r=Emilgardis a=Emilgardis resolves #732 Co-authored-by: Alex Huszagh <ahuszagh@gmail.com> Co-authored-by: Emil Gardström <emil.gardstrom@gmail.com>

Use `readelf -A` on generated binaries to read the target architecture information and output the data as JSON, simplifying verifying that new targets produce code for the desired architecture. Closes cross-rs#821. Related to cross-rs#426.

1018: Update deny list to all system packages for ARMv6 HF. r=Emilgardis a=Alexhuszagh Currently, when using `arm-unknown-linux-gnueabihf`, users frequently try to install packages for the `armhf` Debian architecture, objects which are compiled for ARMv7-A, and therefore are not compatibility with ARMv6 platforms such as the Raspberry Pi 0. This differs from the soft-float targets, where packages for the `armel` architecture are compiled for the ARMv5TE architecture, and therefore are compatible with ARMv5TE, ARMv6, and ARMv7 soft-float targets. Deny-listing all packages for the `armhf` architecture prevents issues such as in #1017, where the use of ARMv7 system packages are linked to the binary, so the resulting binary can no longer be executed on an ARMv6 platform. This is difficult to detect until the user attempts to use the generated objects (binaries, libraries) on native hardware. Also linked is #426. Co-authored-by: Alex Huszagh <ahuszagh@gmail.com>

phuongtran7 mentioned this issue Dec 2, 2021

Failed to cross-compile from Windows to Linux when using target config file. eclipse/paho.mqtt.rust#142

Open

Alexhuszagh added A-arm Area: ARM targets enhancement bug breaking change and removed enhancement labels May 27, 2022

Alexhuszagh mentioned this issue May 31, 2022

s390x toolchain generates binaries for GLIBC 2.18 which is incompatible with RHEL 7 #451

Closed

Alexhuszagh mentioned this issue May 31, 2022

Fix ARMv6 HF image to correctly build for ARMv6 architecture. #734

Merged

bors bot closed this as completed in 5b9a77c May 31, 2022

Alexhuszagh mentioned this issue Jun 10, 2022

arm-unknown-linux-gnueabihf generates dependency on GLIBC_2.28 #712

Closed

Alexhuszagh mentioned this issue Jun 18, 2022

Read Target Architecture Information in XTask #821

Open

Alexhuszagh mentioned this issue Jun 18, 2022

Read target architecture from cross-compiled binaries. #822

Closed

This was referenced Sep 11, 2022

arm-unknown-linux-gnueabihf, gets Illegal Instruction when run on RPI Zero W #1017

Closed

Update deny list to all system packages for ARMv6 HF. #1018

Merged

DarkC35 mentioned this issue Dec 28, 2022

add armv6 target ijl/orjson#330

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Can't target Raspberry Pi 1 and Pi Zero #426

Can't target Raspberry Pi 1 and Pi Zero #426

BrianHoldsworth commented May 22, 2020

schlamar commented May 27, 2020

schlamar commented May 28, 2020

BrianHoldsworth commented May 29, 2020 •

edited

Loading

schlamar commented May 29, 2020

reitermarkus commented May 29, 2020

tmigone commented Jul 31, 2020

BrianHoldsworth commented Aug 3, 2020

zenria commented Sep 20, 2020

BrianHoldsworth commented Sep 23, 2020 •

edited

Loading

zenria commented Sep 23, 2020

BrianHoldsworth commented Sep 23, 2020 •

edited

Loading

chaseboren commented Feb 28, 2021

Alexhuszagh commented May 27, 2022 •

edited

Loading

Can't target Raspberry Pi 1 and Pi Zero #426

Can't target Raspberry Pi 1 and Pi Zero #426

Comments

BrianHoldsworth commented May 22, 2020

schlamar commented May 27, 2020

schlamar commented May 28, 2020

BrianHoldsworth commented May 29, 2020 • edited Loading

schlamar commented May 29, 2020

reitermarkus commented May 29, 2020

tmigone commented Jul 31, 2020

BrianHoldsworth commented Aug 3, 2020

zenria commented Sep 20, 2020

BrianHoldsworth commented Sep 23, 2020 • edited Loading

zenria commented Sep 23, 2020

BrianHoldsworth commented Sep 23, 2020 • edited Loading

chaseboren commented Feb 28, 2021

Alexhuszagh commented May 27, 2022 • edited Loading

BrianHoldsworth commented May 29, 2020 •

edited

Loading

BrianHoldsworth commented Sep 23, 2020 •

edited

Loading

BrianHoldsworth commented Sep 23, 2020 •

edited

Loading

Alexhuszagh commented May 27, 2022 •

edited

Loading