ARM target dependency problems

I am unable to get an executable that runs on the arm7 (i.MX6) target.

Under v1.27 they ran without problem but after updating to v1.33 we ran into a bunch of problems. v1.33 requires I have the toolchain libraries copied over to and pathed onto the target.

.cargo/config (for all our RUST programs) have:
rustflags = ["-c",“prefer-dynamic”]

and in Cargo.toml
crate-type = [“dylib”]

and on the target ‘file’ reveals the following

everything is compiled with

cargo build --target=armv7-unknown-linux-gnueabihf --release

I have copied all the rustup/toolchains/armv7-unknown-linux-gnueabihf/libs to the SSD attached to the target and pathed it with ldconfig /SSD/rustlib

/etc/rc5.d/S98xyz-autostart.sh: line 18: /usr/bin/xyz: No such file or directory

I have tried redoing the permissions and owner, etc. and it refuses to ‘find’ it.

‘cp’ is not a culprit , as I had saved the original rust executables to the SSD (in a backup directory) and can retrieve these previous builds and those executables will run (albeit they have some features missing that I have added to the newer build). The originals were built under v1.27 and the newer builds are compiling under v1.34.

‘file’ shows me the newer executables are similar in nature. both will show

older v1.27 binary
xyz: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/
ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=234bd073a54c4a48ca8b42096a6eada936e9caa4, stripped

newer v1.34 binary
xyz: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, in
terpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=ad1e6b3e33056957d692b82b7a57b7cb58735595, not stripped

I do expect the sha1 to be different. I have copied the toolchain libraries to the external SSD as well as copying the executable’s /deps/*.rlib and *.so to /usr/lib. ldconfg shows these files are pathed to /usr/lib

The target (that the executable has to run on) is an NXP i.MX6 core running Linux v3.14.79

Am I missing something ? or do I have to open an issue?

If you look carefully you see that the interpreter mentioned by the file output is different. The ELF interpreter is responsible for doing dynamic linking at program load time, so if that’s not set correctly, it’s not going to work. Likely the ENOENT you’re getting is for the interpreter, not the executable itself.

The ELF interpreter can be set in a couple of different ways:

  1. As a command line argument to the linker
  2. Hard coded in your cross-linker
  3. In your linker script (I think? Not sure)
  4. Post linking with a tool like patchelf

So there’s probably an issue with your linker configuration.

jethogb. Thank you for your reply. I should have posted the entire .cargo/config so it is clear as to the problem.

[target.armv7-unknown-linux-gnueabihf]
ar = “arm-dey-linux-gnueabi-gcc-ar”
linker = “gcc-sysroot”

[build]
rustflags = ["-C", “prefer-dynamic”]

We are using Digi’s SDK and the environment is sourced for the cross compiler.
source /opt/dey/2.2-r1/environment-setup-cortexa9hf-neon-dey-linux-gnueabi
and our RUST executables compile without errors. Only on the target they fail to run.

The 'export’s show the cross compiler and linker are available …
$ export
declare -x AR=“arm-dey-linux-gnueabi-ar”
declare -x ARCH=“arm”
declare -x AS=“arm-dey-linux-gnueabi-as "
declare -x CC=“arm-dey-linux-gnueabi-gcc -march=armv7-a -marm -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a9 --sysroot=/opt/dey/2.2-r1/sysroots/cortexa9hf-neon-dey-linux-gnueabi”
declare -x CCACHE_PATH=”/opt/dey/2.2-r1/sysroots/x86_64-deysdk-linux/usr/bin:/opt/dey/2.2-r1/sysroots/x86_64-deysdk-linux/usr/bin/…/x86_64-deysdk-linux/bin:/opt/dey/2.2-r1/sysroots/x86_64-deysdk-linux/usr/bin/arm-dey-linux-gnueabi:/opt/dey/2.2-r1/sysroots/x86_64-deysdk-linux/usr/bin/arm-dey-linux-uclibc:/opt/dey/2.2-r1/sysroots/x86_64-deysdk-linux/usr/bin/arm-dey-linux-musl:"
declare -x TARGET_PREFIX=“arm-dey-linux-gnueabi-”

regarding 'linker=gcc-sysroot". gcc-sysroot contents are:
#!/bin/bash
SYSROOT=/opt/dey/2.2-r1/sysroots/cortexa9hf-neon-dey-linux-gnueabi /opt/dey/2.2-r1/sysroots/x86_64-deysdk-linux/usr/bin/arm-dey-linux-gnueabi/arm-dey-linux-gnueabi-gcc --sysroot=SYSROOT (echo “$@” | sed ‘s/-L /usr/lib //g’)

This worked up until v1.33 so I am miffed as to why it won’t execute. Permissions on the target are correct. The xyz.orig was the v1.27 version.
-rwxr-xr-x 1 root root 5585044 May 29 17:07 xyz
-rwxr-xr-x 1 root root 4493656 May 29 15:56 xyz.orig

I have copied over all .rlib and .so files

I’ll review my linker items. They used to work, which is what has me concerned.

Found it.

Buried deep in the system.

Needed to do a 'ln -s ld-2.24.so ld-linux.so.3" so the executable could find it. Nebulous at best. Now the executable runs.

** Closed **

1 Like