前言：
近期想在路由器上装个nohup保证ssh的终端结束后程序还能继续运行，
选择自己编译busybox的nohup用。顺带用musl静态编译不处理依赖问题，还保持小的大小。
实际上就是装了个gcc,g++，最后git clone musl-cross-make，
编译一下，git clone busybox，装个ncursor，配置一下，只选择nohup，配置一些内容，包括静态编译。
下面是ai总结的。
意义不明的ai开头
当我们谈论“编译”时，通常只是执行make，但很少关注它实际执行了什么。make本质上只是根据Makefile去执行一系列命令，这些命令主要是gcc、ld、as等工具。下面以BusyBox为例，直接看交叉编译过程中真实执行的命令。
第一阶段：配置与预处理（没啥用）
编译前需要解决头文件问题。宿主机（x86）有自己的/usr/include，但目标平台（AArch64）需要另一套头文件，这些头文件在工具链的sysroot中。
执行make menuconfig会生成.config，Makefile会把其中的配置转换为编译参数。例如：
aarch64-linux-musl-gcc -E \-D__aarch64__ \-D__linux__ \-DCONFIG_LS=y \-DCONFIG_STATIC=y \-I./include \-I./arch/aarch64/include \-isystem /opt/musl-cross/lib/gcc/aarch64-linux-musl/9.2.0/include \-isystem /opt/musl-cross/aarch64-linux-musl/sysroot/usr/include \shell/ls.c -o shell/ls.i
这里主要有三点：
-D：把配置项变成宏，控制#ifdef分支
-I：项目头文件路径
-isystem：目标系统头文件路径（来自工具链）
如果不使用sysroot，而误用宿主机的/usr/include，会导致错误。例如：
#define __NR_open 2 // x86_64
#define __NR_open 5 // AArch64
系统调用号错误会导致程序运行异常。此外，不同架构的数据类型大小可能不同，结构体布局也会出错。因此必须使用工具链提供的头文件。
工具链命名
编译器名称aarch64-linux-musl-gcc包含目标信息：
aarch64：架构
linux：目标系统
musl：使用的C库
如果架构不匹配（例如32位设备使用aarch64工具链），程序无法运行。
第二阶段：编译（没啥用）
预处理后进入编译阶段。实际执行的核心命令类似：
aarch64-linux-musl-gcc -c -o libbb/trim.o libbb/trim.c
虽然可以拆分为：
gcc -S
as
但实际由gcc内部完成：
gcc├── 预处理├── 编译（cc1）└── 汇编（as）
你看到的完整命令中还包含大量优化和警告参数，这些不影响基本流程。
构建过程中还会执行：
scripts/basic/fixdep ...
这个工具用于处理依赖关系，与交叉编译本身无关。
为什么只需要替换gcc (最重要)
到这里为止，编译流程没有任何变化，唯一不同的是使用了：
aarch64-linux-musl-gcc
而不是：
gcc
原因在于gcc的查找路径是预先配置好的。gcc查找头文件和库的来源有三层：
命令行参数（-I、-L、--sysroot）
环境变量
编译时内置配置（最关键）
工具链在构建gcc时会指定：
--with-sysroot=/aarch64-linux-musl
因此：
#include <stdio.h>
实际查找路径是：
/aarch64-linux-musl/usr/include/stdio.h
库文件查找：
/aarch64-linux-musl/usr/lib/libc.so
系统默认gcc的sysroot是/，所以使用的是：
/usr/include
/usr/lib
即glibc。
而交叉工具链的sysroot指向自己的目录，因此使用的是musl。
此外，aarch64-linux-musl-gcc还会调用同一前缀的工具：
aarch64-linux-musl-as
aarch64-linux-musl-ld
aarch64-linux-musl-ar
这些路径在构建工具链时已经写入gcc（可以通过gcc -v查看）。
工具链的组成
一个工具链通常包含：
gcc
binutils（as / ld / ar）
libc（musl或glibc）
sysroot（头文件和库）
这些组件是一起构建并匹配的，避免版本不一致的问题。