必须用mipsel-linux-gcc而非mips-linux-gcc，因前者为小端mips，适配龙芯1b、君正jz47xx及openwrt路由器；后者为大端，用错将致段错误。
确认你用的是 mipsel-linux-gcc 还是 mips-linux-gcc
这两个名字看着像，但目标 ABI 和字节序完全不同：mipsel-linux-gcc 是小端（little-endian）MIPS，常见于龙芯1B、君正JZ47xx、老款OpenWrt路由器；mips-linux-gcc 通常是大端（big-endian），多见于某些网络设备或旧版Broadcom芯片。用错会导致程序在目标板上直接段错误或无法启动。
验证方式很简单：
- 运行
mipsel-linux-gcc -v，看输出里是否含--with-arch=mips32r2或--with-float=soft—— 这类参数说明它面向嵌入式MIPS32软浮点场景 - 检查工具链解压后的
bin/目录下是否存在对应前缀的可执行文件，别只看名字，要ls -l bin/mipsel-linux-*确认真实存在 - 如果项目文档明确写了“适配 OpenWrt Chaos Calmer”，那基本锁定
mipsel-linux-gcc
编译命令不能直接套用 gcc 参数
mipsel-linux-gcc 不认 -march=native，也不支持 -O3 -flto 这类激进优化（尤其在老版本工具链如 gcc-4.4 上会静默降级或报 internal compiler error）。你得显式告诉它目标 CPU 能力和 ABI。
- 必须加
-march=mips32r2（龙芯1B）、-march=mips32（多数 JZ47xx）或-march=mips2（极老设备） - 浮点处理要明确：
-msoft-float（无FPU，纯软件模拟）或-mhard-float（有FPU，但需配套 glibc 支持） - 避免用
-fPIE或-pie：很多 MIPS 嵌入式系统不支持位置无关可执行文件，链接时会报relocation truncated to fit - 简单测试命令示例：
mipsel-linux-gcc -march=mips32r2 -msoft-float hello.c -o hello_mips
ld 找不到 libc.so？检查 sysroot 和 LD_LIBRARY_PATH
交叉编译不是只换编译器就行，链接阶段需要匹配目标系统的头文件和库。如果你看到类似 cannot find /usr/lib/libc.so 或 undefined reference to `printf'，问题大概率出在 sysroot 路径没对齐。
- 工具链解压后通常带
sysroot/子目录（比如/opt/mips-gcc540-glibc222-64bit-r3.3.0.smaller/mips-linux-gnu/sysroot），必须用--sysroot=指向它 - 动态链接时若提示
libgcc_s.so.1: cannot open shared object file，说明运行时找不到交叉工具链自带的libgcc，需在目标设备上设置LD_LIBRARY_PATH，或编译时加-static-libgcc - 别把主机的
/usr/include当成目标头文件路径——那是 x86 的，混用必炸
WSL 下编译失败报 Value too large for defined data type
这不是交叉编译器的问题，是 WSL2 对 Windows 文件系统（尤其是 /mnt/c/ 下的路径）的 inode 处理缺陷。只要源码放在 /mnt/ 下，哪怕只是 make 一个空 Makefile，都可能触发这个错误。
- 解决办法只有一条：把代码拷到 WSL2 自身的 ext4 分区里，比如
~/project/，再编译 - 验证是否修复：在项目目录运行
ls -li Makefile，如果 inode 号是 6~8 位数字（如263452），就正常；如果是十几位（如123456789012345），说明还在 Windows 文件系统上 - 别试图改 WSL 配置绕过——实测所有 kernel 参数和 fstab 修改都无效，只有挪路径最稳
最容易被忽略的是工具链的 sysroot 是否完整：有些厂商提供的压缩包漏了 usr/include 或 lib 下的关键符号链接，导致 configure 脚本误判 libc 版本。遇到 configure 失败，先 ls -l sysroot/usr/include/asm 看有没有软链接指向 mips，没有就手动建一个。
