Broken cross-compiling setup for Raspberry Pi 3 and Zero

[farnbams]

I setup my machine to cross-compile for Raspberry Pi Zero and 3. This worked for a while now just by installing the required libraries and write the following into ~/.cargo/config:

# for Raspberry Pi 3
[target.armv7-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc-9"
strip = { path = "arm-linux-gnueabihf-strip" }
objcopy = { path = "arm-linux-gnueabihf-objcopy" }

# for Raspberry Pi Zero
[target.arm-unknown-linux-gnueabihf]
linker = "/home/mfs/build-rpi/tools/arm-bcm2708/arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc"
strip = { path = "arm-linux-gnueabihf-strip" }
objcopy = { path = "arm-linux-gnueabihf-objcopy" }

As said this worked perfectly until recently. For another project I installed SEGGER embedded studio. By not looking closely I installed gcc-multilib witch removed the gcc-9-arm-linux-gnueabih package required for the Raspberry Pi 3 linker, i.e. arm-linux-gnueabihf-gcc-9 was no longer available.

I tried to cross-compile my project and of course it failed. After figuring out the issue I installed the correct package again so I thought everything should work fine again. But I got this:

$> RUST_BACKTRACE=1 cargo build --target=armv7-unknown-linux-gnueabihf                    223ms  Do 09:33
   Compiling bitflags v1.2.1
   Compiling ring v0.16.15
   Compiling brotli-sys v0.3.2
   Compiling ryu v1.0.5
   Compiling idna v0.2.0
   Compiling typenum v1.12.0
   Compiling byteorder v1.3.4
   Compiling http-body v0.3.1
error: failed to run custom build command for `brotli-sys v0.3.2`

Caused by:
  process didn't exit successfully: `/home/mfs/workspace/sc-ble-adapter/target/debug/build/brotli-sys-f2455ea365197bc3/build-script-build` (exit code: 1)
--- stdout
cargo:include=/home/mfs/.cargo/registry/src/github.com-1ecc6299db9ec823/brotli-sys-0.3.2/brotli/include
TARGET = Some("armv7-unknown-linux-gnueabihf")
OPT_LEVEL = Some("0")
HOST = Some("x86_64-unknown-linux-gnu")
CC_armv7-unknown-linux-gnueabihf = None
CC_armv7_unknown_linux_gnueabihf = None
TARGET_CC = None
CC = None
CROSS_COMPILE = None
CFLAGS_armv7-unknown-linux-gnueabihf = None
CFLAGS_armv7_unknown_linux_gnueabihf = None
TARGET_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("true")
CARGO_CFG_TARGET_FEATURE = None
running: "arm-linux-gnueabihf-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-march=armv7-a" "-I" "brotli/include" "-o" "/home/mfs/workspace/sc-ble-adapter/target/armv7-unknown-linux-gnueabihf/debug/build/brotli-sys-342a82056dfb826d/out/brotli/common/dictionary.o" "-c" "brotli/common/dictionary.c"

--- stderr
fatal: not a git repository (or any of the parent directories): .git


error occurred: Failed to find tool. Is `arm-linux-gnueabihf-gcc` installed?



warning: build failed, waiting for other jobs to finish...
error: build failed

To me it seems cargo does no longer read ~/.cargo/config but useses some default that is of course not there. Even worse, cross-compiling for the Raspberry Pi 0 doesn't work either despite having not touched the respective linker at all!

Has anyone an idea what is causing this and how I can fix it?

[bjorn3]

Try cargo clean first. There may be something cached.

[farnbams]

Nope didn't work. I also deleted the Cargo.lock, turned my PC off and on and tried different libraries.

[cuviper]

That's coming from the cc crate used in a build script. I think that looks at CC or CC_target environment variables, but off hand I don't know if it ever uses .cargo/config. It does have defaults to use otherwise.

[mbrubeck]

.cargo/config doesn't even have a field for configuring the C compiler. (It specifies the linker, which is often but not always the same program.) There's an open issue discussing this.

[farnbams]

Thank you for your answers so far. I think I'm slowly solving the issue. Cross-compiling for the Raspberry Pi 3 works again . However, for the Pi Zero it still ignores my settings. I did set -x CC_arm_unknown_linux_gnueabihf /my/custom/path (I use the fish shell) and still the result of readelf -A path/to/binary returns Tag_CPU_arch: v7 which should actually be Tag_CPU_arch: v6 for the Pi Zero and was so before I installed gcc-multilib. Is there anything this package sets under the hood? Some envirement variable that cc-crate prefers or paths?