Shared library dependencies on non-x86 target

[gfine]

Again probably another noob question. My thanks to Roland for the help on compiling. Now I have binaries that execute on the target. However, once on the target when the executable is run (after a reboot), I get

: error while loading shared libraries: libstd-42431e74081a30a8.so
: cannot open shared object file : No such file or directory

On the host, I find this library in a sub-directory within .rustup, copy it over to the target, and it is still not found. There also seems to be several .so and .rlib files in the .rustup dir. and where I find them on the target makes no sense. You'd think I'd find them in /lib, but they are in /media/sda1/rustlib. Again no documentation speaks to how these files should be implemented for a RUST executable.
my .cargo/config says

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

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

and I compile as

cargo build --target=arm7-unkknown-linux-gnueabihf --release

and my rustup is v1.34 which was installed (on the host) just before the compile problems were resolved and when I did a build.

and in reading other shared library problem here. The Cargo.toml says:

[package]
name = "xyz-firmware"
version = "0.1.0"
authors = ["previous author's name and e-mail"]

[dependencies]
bytes = "0.4"
futures = "0.1"
futures-cpupool = "0.1"
lazy_static = "1.0"
mio = "0.6"
serde = "1.0"
serde_derive = "1.0"
socketcan = "1.7"
tokio-core = "0.1"
tokio-io = "0.1"
enum-common = { path = "../enum-common" }
enum-derive = { path = "../enum-derive" }
service = { path = "../service" }

[lib]
crate-type = ["dylib"]

[dependencies.sysfs_gpio]
version = "0.5"
features = ["tokio"]

My question is. Do I have to copy all these files to the target or is there a compile time switch for the libraries to be build into the binaries? or is there some other simple fix?

[Michael-F-Bryan]

@gfine

Do I have to copy all these files to the target or is there a compile time switch for the libraries to be build into the binaries?

Rustc normally compiles all dependencies into the binary by default. Because you added rustflags = ["-C", “prefer-dynamic”] to your .cargo/config it told rustc to use dynamic linking, which lets the executable look for a required library on startup.

If you want all dependencies to be compiled into the executable ("static linking") you'll want to remove the "-C", "prefer-dynamic" arguments from your rustflags.

[gfine]

Thank you Michael. I think the original author's desire was to create a smaller footprint on the embedded target and use dynamic libraries.

I did a 'ldconfig /media/sda1/rustlib' and the binaries are happy finding the libraries now. So that cured the not finding of the dynamic libraries.

I hit another snag with the only library the application system has, and it complains of an undefined symbol.

undefined symbol: _ZN7futures9task_impl4core3SET17h94f274ef07e01566E

after that I tried your idea and removed the dynamic verbiage in the .cargo/config. but the error still exists. So onto the next bite of the elephant.