运行时报“no such file or directory”本质是execve()失败，因内核找不到elf文件硬编码的动态链接器（如/lib/ld-linux-riscv64-lp64d.so.1），而非可执行文件本身丢失；可用readelf -l查看interpreter路径，并用patchelf修正或编译时通过--dynamic-linker指定正确路径。
不是程序“找不到文件”，而是运行时动态链接器找不到共享库（.so），或内核找不到解释器（/lib/ld-linux-*.so）
运行时报 No such file or directory 的真实含义
这个错误在交叉编译后很常见，但字面意思极具误导性。它通常不是指你的可执行文件本身丢失，而是：execve() 系统调用失败，因为内核无法加载该 ELF 文件所需的动态链接器（interpreter）。你可以用 readelf -l your_binary | grep interpreter 查看它硬编码依赖哪个解释器路径（如 /lib/ld-linux-riscv64-lp64d.so.1）。如果目标系统上不存在该路径下的解释器，就报这个错。
- 即使你把二进制拷到板子上，只要
ld-linux-*.so不在指定路径，就会触发该错误 - 该错误和
libc.so.6找不到是两回事：前者连 loader 都没起来，后者是 loader 起来了但找不到 libc - 用
file your_binary可确认是否为动态链接、目标架构是否匹配（如ELF 64-bit LSB pie executable, UCB RISC-V）
为什么 clang -target 编出来的二进制默认是动态链接的
LLVM 默认行为是复用主机系统的 sysroot 和 libc 链接策略，除非显式干预。当你只写 clang -target riscv64-unknown-elf ...，它可能仍尝试链接 GNU libc（glibc），而嵌入式常用的是 newlib 或 musl；若用 riscv64-unknown-linux-gnu，则必须确保目标系统有对应版本的 glibc 解释器和共享库。
- 检查是否误用了
-target riscv64-unknown-elf（裸机）却链接了 Linux 的 crt0.o —— 这会导致 interpreter 路径错乱 - 用
clang --target=riscv64-unknown-linux-gnu -v test.c看完整链接命令，重点观察--sysroot=和-dynamic-linker参数是否指向你构建的 sysroot - 加
-static可绕过此问题（但会增大体积、失去 dlopen 能力），适合快速验证逻辑
如何验证并修复 interpreter 路径
最直接的办法是让二进制使用目标系统上真实存在的解释器路径。不要靠复制头文件解决，这是运行时问题，不是编译时问题。
- 先在目标系统上运行
cat /proc/sys/kernel/hostname确认架构，再查ls /lib/ld-linux*或find / -name 'ld-linux*' 2>/dev/null得到真实路径 - 用
patchelf --set-interpreter /lib/ld-linux-riscv64-lp64d.so.1 your_binary重写 interpreter 字段（需提前安装 patchelf） - 更稳妥的方式是在编译时就指定：
clang -target riscv64-unknown-linux-gnu --sysroot=/path/to/riscv-sysroot -Wl,-dynamic-linker,/lib/ld-linux-riscv64-lp64d.so.1 ... - 如果目标系统用的是 musl，解释器通常是
/lib/ld-musl-riscv64.so.1，路径和名字都不同，不能混用
最容易被忽略的是：解释器路径是硬编码进 ELF 的，且大小固定；改错一个字符（比如多一个 d 或少一个 64）就会导致 No such file or directory。务必用 readelf 反复核对，而不是凭记忆写路径。
