Thanks for your explanation. I now see indeed that it is requesting an interpreter I do not have.:
$ readelf -l target/arm-unknown-linux-gnueabihf/debug/rust_hello |grep interpreter
[Requesting program interpreter: /lib/ld-linux.so.3]
on the target system:
root@ctrl2019_1:/lib# ls |grep linux
ld-linux-armhf.so.3
So, I created a symbolic link to ld-linux-armhf.so.3, and now it works! Apparently they're compatible. Thanks you for your great advise!
Final question: Am I using the wrong toolkit maybe? Why is it referring to a different library? I rather not want to add this symbolic link for production; I am not a 100% there two interpreters are compatible in every case. Any insight would be most helpful.
I think it would work as-is with rust target arm-unknown-linux-gnueabi instead of arm-unknown-linux-gnueabihf. I don't have any non-hf targets to check but most likely the dynamic linker name /lib/ld-linux.so.3 is the non-hardfloat one.
Careful: just because they link doesn't mean they're actually compatible at runtime. For example, if you build with a --target which includes gnu it's expecting that glibc will be present and will behave in certain ways. For example, rust on glibc gets its std::env::args from a nonstandard place, which is left as uninitialized memory in other libc implementation. This is just an example of what can go wrong; I'm sure there's others. However if your libc on the board is actually glibc, you might be ok! (There still might be differences between the headers you used at compile time and the built system which could bite you, though!)
The rust compiler will actually use the linker from poky, if you use it correctly.
The problem with the wrong linker is not just a rust problem, I had lots of issues with the poky SDK using the wrong dynamic linker name in some circumstances. C/C++ code using poky SDK is also using wrong linker name sometimes.
I did however not discover, why the poky linker fails to set the correct dynamic linker.
Tip:
Use rustc -Clink-args=--dynamic-linker=<CORRECT_LINKER>, and it will use the correct linker. You may want to add this linker argument to your .cargo/config.