结论是：-m32只是触发开关，真正报错根源是缺失32位系统库和头文件；centos/rhel需装glibc-devel.i686、libgcc.i686等，ubuntu/debian需装gcc-multilib及libc6-dev-i386，否则编译器无法找到gnu/stubs-32.h、sys/cdefs.h等关键头文件。
直接说结论：在 64 位 Linux 系统上用 gcc -m32 编译 32 位程序，-m32 本身只是开关，真正卡住你的通常是缺失的 32 位系统库和头文件——不是参数写错了，是环境没配齐。
为什么加了 -m32 还报 gnu/stubs-32.h: No such file or directory？
这是最典型的“参数能认、编译器却找不到 32 位标准头文件”的表现。GCC 启用 -m32 后会去 /usr/include/asm、/usr/include/gnu 等路径找 32 位专用头，但默认只装了 64 位头文件。
- CentOS/RHEL/Fedora：必须装
glibc-devel.i686（不是glibc-devel） - Debian/Ubuntu：对应的是
libc6-dev-i386 - 如果还报
bits/predefs.h或sys/cdefs.h找不到，说明gcc自身的 multilib 支持没装全，Debian 系要补gcc-multilib，RHEL 系确认glibc-devel.i686和libstdc++-devel.i686都已安装
链接阶段失败：cannot find -lgcc_s 或 /usr/lib32/libc_nonshared.a
-m32 不仅影响编译，还强制链接器去找 /usr/lib32 下的 32 位运行时库。但很多 64 位系统默认不带这个目录，或里面缺关键文件。
- 检查是否存在
/usr/lib32：没有就说明 32 位库根本没装 - RHEL/CentOS：运行
yum install libgcc.i686 libstdc++.i686 glibc.i686 - Ubuntu/Debian：运行
apt install gcc-multilib（它会自动拉入libc6-dev-i386、libgcc1:i386等） - 若仍报
cannot find -lc，试试显式加-L/usr/lib32，但更推荐先装全依赖，避免硬编码路径
验证生成的确实是 32 位可执行文件
file 命令是最可靠判断方式，别信文件名或编译命令里有没有 -m32。
- 成功输出应含
ELF 32-bit LSB executable, Intel 80386或类似字样 - 如果显示
ELF 64-bit LSB executable, x86-64，说明-m32没生效——要么被 Makefile 里其他 CFLAGS 覆盖，要么 GCC 实际调用的是不支持 multilib 的精简版（比如某些容器镜像里的gcc） - 用
readelf -h a.out | grep Class看是否为CLASS: ELF32，比file更底层、更不易误判
Makefile 里怎么安全加 -m32？
别直接改全局 CFLAGS = -m32，容易污染其他目标；也别只在链接行加，编译和链接必须一致。
- 推荐写法：
CFLAGS += -m32（注意是+=，不是=），并在链接命令里确保LDFLAGS也继承该设定 - 如果项目混用 C/C++，C++ 部分还要确认
libstdc++的 32 位版本已安装，否则g++ -m32会静默失败或链接时报 undefined reference - 交叉编译场景下，
-m32不等价于真正的交叉工具链（如i686-linux-gnu-gcc），它依赖宿主系统提供完整 32 位生态，不适合构建嵌入式或严格隔离环境
真正麻烦的从来不是 -m32 这个参数本身，而是它背后暴露的整个 32 位兼容层是否完整——装包、路径、ABI、甚至内核模块支持（比如某些驱动只提供 64 位版本），都可能让一个看似简单的编译中断在最后一步。
