"No such file or directory" error when running a dynamically-linked ARM executable - linux

Question

I am cross-compiling for an ARM embedded Linux platform running Ubuntu 15.04. Previous, statically-linked, versions of this program have run just fine. Recently I needed to link in libproprietary (lib name changed for this question), which is only available as an .so.
libproprietary.so works; I am able to run a different program that depends on it.
$ uname -a
Linux <hostname> 3.10.92-71 #1 SMP PREEMPT Fri Dec 18 00:38:54 BRST 2015 armv7l armv7l armv7l GNU/Linux
The problem:
$ ./myprogram
-bash: ./myprogram: No such file or directory
What I've tried:
$ ldd ./myprogram
libproprietary.so.2 => /usr/lib/libproprietary.so.2 (0xb6bbc000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6ba6000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6b92000)
libusb-1.0.so.0 => /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (0xb6b72000)
libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6ab8000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6a43000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6955000)
/usr/lib/ld.so.1 => /lib/ld-linux-armhf.so.3 (0xb6f28000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb692c000)
libudev.so.1 => /lib/arm-linux-gnueabihf/libudev.so.1 (0xb690f000)
$ file ./myprogram
./myprogram: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=881d76b2ce20f32aef95796b4fee9f01e492a7d2, not stripped
$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a687c2baf9963c62c6abd209863d360dd0863686, stripped
$ readelf -l myprogram| grep interpreter
[Requesting program interpreter: /usr/lib/ld.so.1]
$ strace ./myprogram
execve("./myprogram", ["./myprogram"...], [/* 21 vars */]) = -1 ENOENT (No such file or directory)
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1) = ?
+++ exited with 1 +++
$ ls -l myprogram
-rwxrwxr-x [details snipped]
$ file /usr/lib/libproprietary.so.<version>
/usr/lib/libproprietary.so.<version>: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=d9b4ba3b9ec03779792984bc8a89ceede5737455, stripped
It appears that the interpreter, /usr/lib/ld.so.1, does not exist. I'm going to guess that it should be similar to what /bin/ls is using:
$ readelf -l /bin/ls | grep interpreter
[Requesting program interpreter: /lib/ld-linux-armhf.so.3]
I don't know how to fix this in my link step however.
ccache arm-linux-gnueabihf-g++ -o myprogram -static -Wl,--whole-archive -lpthread -Wl,--no-whole-archive -Wl,-no-undefined -pthread -Wl,-Bdynamic -lproprietary -Wl,-rpath-link=result/debug/lib -Wl,-rpath=\$ORIGIN/../../../../result/debug/lib variant-dir/debug/core-.o -Lresult/debug/lib -Wl,-Bstatic -l<other libs>
I did try moving -Wl,-Bdynamic -lproprietary after the core-.o word, but that didn't change anything.

Answer 1

It appears that the interpreter, /usr/lib/ld.so.1, does not exist. I'm going to guess that it should be similar to what /bin/ls is using:
Correct. You could change the interpreter by adding -Wl,--dynamic-linker=/lib/ld-linux-armhf.so.3 flag at link time.
However,
Your toolchain may be targeting a different version of libc from the one you actually have installed (in which case the program will likely crash).
If it is targeting correct libc, then your toolchain is mis-configured.