Hi!
I need some support, again. Currently i set up an 'minimal embedded linux' with the help of buildroot, which runs on a raspberry PI 4. As in my other thread mentioned, I need some 'drivers' for different sensors, which I have written in Rust. When writing these, i used the 0815 raspbian os, which has 'everything' on board and also a lot of boilerplate stuff so my final goal is to have only the kernel running with minimal overhead.
Now i have to compile the Rust-Sources from my host (x86_64) to the aarch64 Architecture. There are a bunch of tutorials, so it outcomes like this:
foo: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=e17920ca987e387e221bb5a32e0c0d347294b421, for GNU/Linux 3.7.0, with debug_info, not stripped
So far so good. When running it on my custom buildroot linux, the outcome looks like that:
# ./foo
-/bin/sh: ./foo: not found
Oops, but the file is there! Okay, i found out, that the problem occurs because of the dynamic linking and, of course, on my system almost nothing exists. If i copy 'ld-linux-aarch64.so.1' into /lib, the programs 'starts', but claims the next missing lib.
Long story short: Is there a way to compile every dynamic lib into the binary so that it may run standalone? I searched a while for it and found nothing appropriate for this use case.
In C language it's really simple to do this and I get programs running standalone on this 'minimal linux', but hey, rewrite the driver in C would feel like i 'lost the war'. Would be great to 'embedd' rust programs into buildroot
Edit:
My C Programs look like this:
# file am2302
am2302: ELF 64-bit LSB executable e, ARM aarch64, ....
So propably we need an executable instead of 'shared object'