ldd报“not a dynamic executable”说明文件非动态可执行格式，主因是缺失.dynamic段（如静态链接、裸对象或abi错配），file命令显示“statically linked”或非elf格式即可确认。
直接看 ldd 和 file，90% 的“无法运行”问题出在这两个命令的输出里。
程序是不是根本没链接成功？用 ldd 看动态依赖
很多所谓“无法运行”，其实是启动时被内核直接拒载——execve 返回 No such file or directory，哪怕文件明明存在。这不是路径错了，而是解释器（INTERP）找不到。
-
ldd ./myprog如果第一行就报not a dynamic executable，说明你用了-static或忘了加-shared，但更常见的是：你用clang编译却没走lld或系统ld，导致生成了不带解释器段的裸对象 - 如果
ldd显示某库是not found（比如libstdc++.so.6 => not found），别急着装包——先readelf -d ./myprog | grep interpreter确认它想用哪个/lib64/ld-linux-x86-64.so.2；再ls /lib64/ld-linux-x86-64.so.2看是否存在。交叉编译时尤其容易错配解释器路径 -
ldd本身会尝试加载所有依赖，某些环境（如容器、chroot）下它可能假阳性报not found，此时应改用readelf -d ./myprog | grep NEEDED+ 手动find验证
程序架构和 ABI 对不对？用 file 和 readelf -h 快速对焦
Clang 默认行为比 GCC 更“诚实”：你没显式指定 --target，它就按 host 构建；但如果你在 x86_64 主机上编译 ARM64 位码，又忘了配 --sysroot，生成的 ELF 头可能合法但 ABI 错配，Linux 内核直接拒绝加载。
-
file ./myprog必须明确显示类似ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked—— 注意中间的x86-64（或AArch64）和dynamically linked。若写的是data或current ar archive，说明你误把 bitcode（.bc）当可执行文件了 -
readelf -h ./myprog | grep -E 'Class|Data|Machine|OS/ABI'重点核对：Class是 ELF64 还是 ELF32；Machine是否匹配目标 CPU（Advanced Micro Devices X86-64vsARM）；OS/ABI是SYSV（Linux 标准）还是GNU（通常兼容），若出现none或standalone，大概率是裸机/嵌入式链接脚本漏设 ABI - Clang + LLD 组合下，若忘记加
-pie编译位置无关可执行文件，而系统启用了CONFIG_LEGACY_VSYSCALL_NONE（较新内核默认），也会静默失败——file会显示not pie，这就是线索
入口点和符号导出有没有被优化掉？检查 nm 和 llvm-readobj
LLVM 中端优化激进，-O2 及以上可能把 main 函数内联进 _start，或因未声明 extern "C" 导致 C++ 符号名修饰（mangling）后找不到入口；更隐蔽的是，你用 clang --target=armv7a-none-eabi 编译裸机固件，但链接时没提供 _start，LLD 默认不报错，只生成一个无入口点的 ELF。
-
nm -D ./myprog | grep main—— 动态符号表里必须有T main（大写 T 表示代码段定义）。若只有U main（undefined），说明链接时没找到实现；若完全没输出，说明被-ffunction-sections -Wl,--gc-sections删掉了，或main被static修饰 -
llvm-readobj -sections ./myprog | grep -A5 -B5 start查看是否有.text.startup或显式_start段；对 Linux 用户程序，readelf -s ./myprog | grep -w _start应返回一个定义符号，否则 loader 不知道从哪开始 - Clang 编译 C++ 时，若主文件是
.cpp但没加-x c++，可能被当 C 解析，导致main函数签名不匹配（int main()vsint main(int, char**)），nm会显示修饰后的符号如_Z4mainv，loader 找不到main
真正难缠的不是链接失败或架构错配，而是程序能启动、立刻 segfault 却没 core dump——这时候得怀疑 __libc_start_main 调用链被破坏，或者 Clang 生成的栈保护（-fstack-protector-strong）与 libc 的 canary 初始化不兼容。这种问题不会出现在 file 或 ldd 输出里，必须上 gdb ./myprog 看 catch syscall execve 后的第一条指令地址是否合法。
