企业官网建设流程全解析

简介：gcc-3.3.6.tar.gz 是 GNU 编译器集合 3.3.6 版本的完整源码归档，面向嵌入式开发、交叉编译工具链构建与操作系统移植的开发者，尤其适合需要为特定目标架构定制编译器的中高级用户。压缩包约 2000 个文件、整体 30.03MB，以 C 源码（7828 个 .c）、Java 与 C++ 源码（2027 个 .java、455 个 .cc）、头文件（1243 个 .h）为主体，另含 Ada 的 .ads/.adb、Fortran 的 .f、汇编 .s/.asm、configure 与.am/.m4 构建脚本、texi 文档及大量 t-* 目标平台模板，覆盖前端解析、中间优化、后端代码生成与运行时库的完整结构。解压后可从 parse.c、expr.c、decl.c、combine.c、dwarf2out.c 等文件入手研读编译流程，配合 configure 的 --target/--prefix 选项完成定制、编译与测试。已有 221 人学习下载，可作为工具链搭建与 GCC 内部机制研究的基础素材。

1. 某实验室的工控板卡要重烧固件，最后卡在一个 2003 年的编译包上

上个月接的活：某实验室一台停线多年的工控设备要重新烧固件，源码在，Makefile 也在，唯独当年那套交叉工具链没留备份。拿现在系统里的 gcc 编出来的二进制丢上去，轻则链接阶段就挂，重则能跑但行为飘——结构体布局、内联策略、老式扩展写法，全在版本边界上。gcc-3.3.6.tar.gz 就是那一代编译器的完整源码发布包，前端、后端、运行时库、文档生成脚本都在里面。它解决的不是“学编译原理”的问题，而是“让一份按老编译器行为写死的代码重新编出来”的问题，适合手上有老设备、老内核模块，或者需要复现十多年前构建产物的从业者。

2. 先确认 3.3.6 能不能干你的活：版本边界与构建前提

动手之前有一件事必须先想清楚：你要的到底是“一个 3.3.6 的编译器”，还是“一段按 3.3.6 行为编译出来的二进制”。这两件事的构建路径完全不同，前者装完就完事，后者还牵扯目标 C 库、启动文件和老 sysroot。这一节把版本位置、依赖条件和环境隔离理顺，后面两条路线才好选。

2.1 3.3 这一代在 GCC 谱系里的位置

3.3 分支是 C89 时代末期的产物，分支末尾的补丁版本修的都是编译崩溃和目标平台适配，语言特性层面没有新增。它默认的语言标准是 gnu89，接受 K&R 风格的函数定义和隐式函数声明；C++ 前端还是旧式解析器，对模板的处理和今天差别很大，很多现代写法在这一版上会直接报语法错误。这些都是后面踩坑的根源。

一个对现代宿主很友好的点是：3.3 不依赖 GMP、MPFR、MPC 这几个数学库（那是 4.3 之后才引入的强依赖），所以 configure 阶段没有一堆--with-gmp=/path的配置烦恼，安装门槛反而比想象中低。代价是它没有插件框架、没有 LTO、没有-fplugin，你别指望在它上面做什么现代优化实验。

更要紧的是 ABI 层面：x86-64 的调用约定在 3.3 时期已经定型，所以它生成的目标文件在现代系统上通常能正常加载和执行。真正容易翻车的不是生成的代码，而是编译过程中吃进去的头文件——用 2020 年代的 glibc 头文件去喂一个 2003 年的编译器，ssize_t、S_IFDIR这类定义位置变了，报错会从各种意想不到的地方冒出来。

我一般把需求分成三类来判断值不值得上这个包：第一类是复现老固件、老驱动的构建，源码里可能有__attribute__的旧用法或依赖特定内联行为，这类最需要原版本；第二类是编译只在 3.x 上通过的老 C++ 代码，旧解析器容忍一些今天不合法的写法；第三类是教学和研究，想读一个结构完整、体量可控的老编译器源码。三类之外的需求，比如“想在新项目里用老版本图个稳定”，趁早放弃，收益为负。

2.2 构建机上必须先备齐的四样东西

宿主 C 编译器是第一道门槛。最舒服的组合是宿主默认 gcc 在 4.x 到 9.x 之间，这些版本对 C89 代码足够宽容。宿主 gcc 到 10 以上就开始难受了：默认-fno-common会让老代码里的 tentative definition 变成重复定义，默认 PIE 会让某些 configure 探测程序的链接方式变化，默认 gnu17 标准会直接拒绝 K&R 风格的函数定义。不是说不能用新宿主，而是你得手动把这几项掰回去，后面第三章会给具体开关。

第二样是 binutils，也就是as和ld。编译过程中汇编器和链接器一直在被调用，版本太新一般问题不大，但如果你要做交叉工具链，目标架构的 binutils 必须先编好并放进 PATH，否则 configure 探测目标汇编器会直接失败。

第三样是 GNU make。老式 Makefile 对并行构建的支持不算完美，某些目标在-j下会偶发顺序问题，心里要有数。

第四样是可选的文档工具链：texinfo、gperf、flex、bison。texinfo 只影响 info 文档生成，缺了会在 make 最后阶段报错但产物已经出来了；gperf 影响 libstdc++ 的部分生成步骤，只做 C 前端可以完全绕开；flex/bison 在发行版 tar 包里其实已经带了预生成的解析器，一般用不上，但装了不亏。用你镜像里的包管理器把它们一次装齐，省得中途被打断。

磁盘上留出 2 到 3 GB，源码树解开一百多兆，构建树会长到它的十倍以上。时间上，单核跑完一次完整构建大概半小时上下，-j4能压到十几分钟，开了--disable-bootstrap还能再快一截。

2.3 把构建环境关进笼子：目录布局与容器隔离

老编译器构建最怕的事情是“污染”：你在系统/usr/include下编出来的东西，悄悄混进了宿主的头文件，编出来的工具链在你这台机器上能跑，换台机器就废。所以目录布局要一开始就定死，源码、构建、安装三处分离：

# 三个目录各司其职，构建目录不放在源码树里 mkdir -p /opt/src /opt/build /opt/toolchain cd /opt/src tar -xzf /path/to/gcc-3.3.6.tar.gz # 解出 gcc-3.3.6/ mkdir -p /opt/build/gcc-3.3.6 cd /opt/build/gcc-3.3.6

源码解压在/opt/src，构建在/opt/build，最终装到/opt/toolchain下面带版本号的前缀里。这样做的好处是：想重来一遍，直接rm -rf /opt/build/gcc-3.3.6重建目录就行，不用重新解包；想同时留两个不同配置的版本，改个前缀就并存了。

如果我判断宿主环境本身就不合适（比如宿主默认 gcc 已经是 13、14），我会干脆开一个容器把整件事关进去，用老一点的系统镜像，或者现代镜像里额外装一个 4.8 左右的 gcc 当引导编译器：

# 镜像名按你手头有的挑，关键是把工作目录挂进去，别在容器里存源码 docker run -it --rm \ -v /opt/src:/opt/src \ -v /opt/build:/opt/build \ -v /opt/toolchain:/opt/toolchain \ <你选的老系统镜像> /bin/bash

容器方案的价值不在隔离本身，而在于可重复：你调通的那一套命令，隔半年换台机器，用同一个镜像还能原样跑一遍。血泪经验是，直接在生产开发机上编老工具链，过几个月准忘了当时改过哪些系统头文件。

3. 一次完整的三段式构建：configure、make、install 逐条拆

构建流程本身不复杂，复杂的是每个开关背后的取舍。这一章按执行顺序走，每个阶段都给出可直接抄的命令，代码后面把参数为什么这么设、失败了先看哪里讲清楚。新手照着敲能出结果，熟手可以对着参数说明改自己需要的组合。

3.1 configure：开关不是越多越好

先给一份我常用的最小可用配置，纯本机使用、只要 C 和 C++ 前端：

cd /opt/build/gcc-3.3.6 CC="gcc -std=gnu89 -fcommon -fno-stack-protector -fno-pie" \ CXX="g++ -std=gnu++98 -fpermissive -fno-stack-protector -fno-pie" \ /opt/src/gcc-3.3.6/configure \ --prefix=/opt/toolchain/gcc-3.3.6 \ --build=x86_64-pc-linux-gnu \ --enable-languages=c,c++ \ --disable-bootstrap \ --disable-nls \ --disable-shared \ --disable-libgcj \ --enable-threads=posix \ 2>&1 | tee configure.log

第一行把兼容开关塞进CC和CXX环境变量，这是关键。-std=gnu89让编译器和 configure 阶段的探测程序都按老标准解释源码，避免隐式声明被当成错误；-fcommon抵消新宿主默认-fno-common带来的重复定义；-fno-stack-protector和-fno-pie是为了让 configure 里那些“编译一个空 main 看能不能过”的探测不被新默认值干扰。这几个开关如果只在 make 阶段加，configure 阶段照样会挂，所以必须提前。

--build显式写死宿主三元组，作用是绕过源码里那份 2003 年的 config.guess。老 config.guess 在新架构（比如 ARM64 宿主机）上会直接报unable to guess system type，手动指定最省事。--enable-languages=c,c++只建两个前端，java 前端会拖进 zlib 和一堆额外依赖，直接--disable-libgcj关掉。--disable-bootstrap让构建只走一遍，用宿主编译器直接产出最终编译器，省掉三阶段自举的时间和不确定性——代价是失去自检，编出来的编译器如果本身有 bug 不会被发现。做产品级工具链时我会把它打开，做一次性复现时关掉。

--disable-nls去掉多语言支持，少一个 gettext 依赖。--disable-shared让 libstdc++ 走静态，这对后面做交叉工具链几乎是必须的：目标板上不一定有对应版本的libstdc++.so，静态链接能省掉一整类运行时找不到库的问题。本机使用的话这项可有可无。

configure 挂了不要慌，第一时间看同目录下的config.log，里面记录了每一个探测程序编译失败时的完整命令行和错误输出：

# 找最后一个失败的探测，通常在文件末尾附近 tail -80 configure.log grep -n "cannot create executables\|error:" configure.log | head -20

configure: error: C compiler cannot create executables是最常见的一条，原因九成在上面那几个兼容开关没加对，或者宿主的头文件路径有问题，config.log里能直接看到是哪个-I路径导致的。

3.2 make：并行、日志与第一次失败怎么读

configure 通过之后就可以开编。我习惯把输出全量落盘，因为失败点经常在几千行之前：

make -j"$(nproc)" 2>&1 | tee build.log echo "make exit=${PIPESTATUS[0]}"

PIPESTATUS[0]取的是 make 自己的退出码，不是 tee 的，这一点很关键——不写这行，管道会吞掉失败状态，你以为编成功了其实早就挂了。日志文件是后续排查的唯一依据，别嫌占地方。

失败之后不要从日志末尾开始读，末尾通常是一堆连锁反应。正确的读法是找第一个真正的错误：

grep -n -m 5 -E "^make.*Error|error:|undefined reference to" build.log

拿到行号往上翻二三十行，看是哪个源文件、哪个编译单元出的事。典型的三类初次失败：一是头文件相关，比如error: 'S_ISDIR' undeclared，说明新版 glibc 把某些宏挪了位置，这时候要么加-D_GNU_SOURCE，要么换用老的 sysroot；二是重复定义，multiple definition of 'xxx'，前面-fcommon没生效或者被 Makefile 内部覆盖了；三是老代码里的隐式函数声明被新宿主当错误，加-Wno-error=implicit-function-declaration或者确认-std=gnu89真的传进去了。

判断开关有没有传进去，最土也最有效的办法是看 make 打印出来的实际编译命令行，搜一个具体文件名：

grep -m 3 "gcc .*insn-emit" build.log

如果命令行里看不到-std=gnu89，说明某个 Makefile 变量把 CFLAGS 覆盖了，得改成make CFLAGS="..." CXXFLAGS="..."的形式显式传。

3.3 install 与自检：三条命令确认编译器真的能用

编译通过之后安装，然后立刻做三件事，缺一不可：

make install /opt/toolchain/gcc-3.3.6/bin/gcc -v /opt/toolchain/gcc-3.3.6/bin/gcc -dumpmachine printf 'int main(void){return 0;}\n' > /tmp/t.c /opt/toolchain/gcc-3.3.6/bin/gcc /tmp/t.c -o /tmp/t && /tmp/t && echo "RUN OK"

第一条打印版本和 configure 时的完整参数，用来确认你想要的开关真的生效了，尤其是--enable-languages和--disable-shared。第二条打印默认目标三元组，本机构建时应该和宿主一致，后面做交叉时这里是验证的关键。第三条用一个空 main 走完“预处理、编译、汇编、链接”全链路，能跑通说明 crt 文件、libc、libgcc 都找得到。

再补一条检查搜索路径，交叉场景下特别有用：

/opt/toolchain/gcc-3.3.6/bin/gcc -print-search-dirs

输出的install:和programs:两行应该都指向你的 prefix，如果里面混进了/usr/lib/gcc/...，说明安装布局有问题，通常是 configure 时--prefix和--with-sysroot一起用导致的。

用的时候别改全局 PATH，容易和系统 gcc 打架。我一般是在具体项目的构建脚本里前置一行：

export PATH=/opt/toolchain/gcc-3.3.6/bin:$PATH

4. 交叉工具链：把 3.3.6 变成目标架构的编译器

本机构建只是热身，真正需要这个包的人，十有八九是要给另一套架构出二进制。交叉构建的复杂度不在 configure 参数，而在于你要清楚“编译器、C 库、目标头文件”三者的先后依赖关系，顺序错了就是无限循环的报错。

4.1 为什么必须分两阶段，而不能一把梭

一个完整的编译器要能生成可执行文件，需要目标平台的启动文件（crt1.o 之类）和 C 库。而目标 C 库本身又要用编译器编出来。这是个鸡生蛋问题，标准解法是两阶段：

第一阶段先编一个“没有 C 库也能工作”的编译器，它只包含 C 前端和后端，能生成汇编和目标文件，但不能链接出完整可执行程序。这一步用--without-headers配--with-newlib，绕开对目标头文件的依赖。

第二阶段用这个半成品编译器去编译目标 C 库，装进 sysroot，然后再用同一份源码、加上--with-headers指向 sysroot，重新配置构建一次完整编译器。这时候它就有完整的头文件和库可用了。

顺序上还有一件事必须提前：目标架构的 binutils 要先编好装好，因为 GCC 的 configure 会去 PATH 里找<target>-as和<target>-ld，找不到就直接失败。binutils 的编译比 GCC 简单得多，configure 加--target=加--prefix=三条就够，这里不展开。

先确认你手上这个 3.3.6 支不支持 sysroot，不同补丁版本行为有差异：

/opt/src/gcc-3.3.6/configure --help | grep -i sysroot

有输出就走 sysroot 路线，干净利落；没有输出就退回--with-headers加--prefix的传统布局，靠目录结构把目标库和宿主库隔开。

4.2 三元组、sysroot 与头文件的三条路径

假设目标是 ARM EABI，先约定好 sysroot 的结构，这一步做对了后面省一半事：

/opt/arm-sysroot/ ├── usr/ │ ├── include/ # 目标平台头文件 │ └── lib/ # 目标平台库，含 crt*.o └── lib/ # 动态加载器

第一阶段构建，只要 C 前端，不要 C 库：

mkdir -p /opt/build/gcc-arm-stage1 && cd /opt/build/gcc-arm-stage1 CC="gcc -std=gnu89 -fcommon -fno-pie" \ /opt/src/gcc-3.3.6/configure \ --prefix=/opt/toolchain/arm-3.3.6 \ --build=x86_64-pc-linux-gnu \ --host=x86_64-pc-linux-gnu \ --target=arm-linux-gnueabi \ --with-sysroot=/opt/arm-sysroot \ --without-headers \ --with-newlib \ --enable-languages=c \ --disable-shared \ --disable-nls \ 2>&1 | tee configure-stage1.log make -j"$(nproc)" all-gcc 2>&1 | tee build-stage1.log make install-gcc

--target决定产物的名字前缀，装出来就是arm-linux-gnueabi-gcc，这个名字也决定了它去 sysroot 里找usr/lib还是lib。--host和--build都写成宿主，表示这是个“在 x86-64 上跑、给 ARM 编”的交叉编译器。all-gcc这个 make 目标只构建编译器本体，不构建目标库，正是第一阶段要的东西。install-gcc同理，只装编译器。

第二阶段在目标 C 库装进 sysroot 之后进行，参数上把--without-headers --with-newlib换成：

--with-headers=/opt/arm-sysroot/usr/include \ --with-sysroot=/opt/arm-sysroot \

其余不变，但要记得清空构建目录重来一遍，别在 stage1 的目录上续编，Makefile 里残留的变量会让你怀疑人生。

4.3 最小验证链：从编译到 ELF 头部逐层确认

工具链装完，用一条最小链路验证，每一步都能定位到具体环节：

cat > /tmp/hello.c <<'EOF' #include <stdio.h> int main(void) { puts("hello from 3.3.6"); return 0; } EOF export PATH=/opt/toolchain/arm-3.3.6/bin:$PATH arm-linux-gnueabi-gcc -v arm-linux-gnueabi-gcc /tmp/hello.c -o /tmp/hello file /tmp/hello arm-linux-gnueabi-readelf -h /tmp/hello | grep -E 'Machine|Flags|Type' arm-linux-gnueabi-readelf -d /tmp/hello | grep NEEDED

file应该报ELF 32-bit LSB executable, ARM, EABI5；readelf -h里的Machine是ARM，Flags里能看到 EABI 版本号。这两条确认的是“编出来的是不是目标架构的二进制”，而不是宿主架构误编。

最后一条readelf -d看动态依赖。如果目标板子的根文件系统和 sysroot 里的库版本对不上，这里会出现NEEDED libc.so.6但板子上没有对应版本，运行时直接报找不到库。稳妥做法是对老设备一律加-static，把所有依赖吃进可执行文件里：

arm-linux-gnueabi-gcc -static /tmp/hello.c -o /tmp/hello-static file /tmp/hello-static # 应显示 statically linked

5. 避坑：编译 3.3.6 最常翻的五个车

这几个坑我几乎每次重装都要重踩一遍，整理成“现象、原因、解决”三段，出问题时直接对着症状找。

5.1 configure 报 C compiler cannot create executables

现象：configure 跑到一半退出，日志里就这一行，看不出所以然。

原因：config.log里才有真相。最常见的是宿主 gcc 默认开了 PIE，而老 configure 的探测程序用-nostdlib加自定义链接脚本，两者冲突；其次是新版 gcc 把隐式函数声明当硬错误，探测程序本身编不过。

解决：先grep -n "cannot create executables" config.log定位，再往上看最近一次失败的完整编译命令，把那条命令复制出来手工跑一遍，错误就明了了。多数情况加-fno-pie -no-pie -std=gnu89 -fcommon能过。如果报的是找不到某个头文件，检查是不是CPATH或C_INCLUDE_PATH环境变量污染了头文件搜索路径。

5.2 链接阶段大面积 multiple definition

现象：编译都过了，链接时报几十个multiple definition of 'xxx'，符号看着都是些不起眼的小函数。

原因：宿主 gcc 10 以后默认-fno-common，老代码里大量使用 tentative definition（头文件里写int foo;，多个 .c 包含后各自定义一份），在新默认值下就变成重复定义。

解决：确保-fcommon真的传到了每一个编译单元。检查办法是grep -m 5 "gcc .*-c " build.log | head，看命令行里有没有这个开关。没生效就在 make 时显式传CFLAGS="-O2 -fcommon -std=gnu89"。注意-fcommon是编译期开关，链接期加没用。

5.3 最后阶段 makeinfo 报错，构建中断

现象：编译器本体都编完了，卡在生成文档那一步，报makeinfo: unrecognized option或者语法错误。

原因：新版 texinfo 对老.texi文件的语法检查更严格，老文档里有今天不合法的写法。

解决：文档不是必需品。make 时把 MAKEINFO 变量指成 true 直接跳过：

make -j"$(nproc)" MAKEINFO=true 2>&1 | tee build.log

如果已经编到一半，重跑这条命令即可，前面编好的目标不会重编。更彻底的做法是装一份和那个年代匹配的老 texinfo，但为了几页 info 文档不值得。

5.4 libstdc++ 编译失败，报模板相关语法错误

现象：C 前端全过，编到libstdc++-v3目录下开始报错，错误信息集中在模板特化和命名空间上。

原因：libstdc++ 的源码是按当时的 C++ 前端写的，用新宿主 g++ 编会撞上标准演进带来的语法收紧。3.3 自带的 C++ 前端本身是旧解析器，它编自己的库没问题，问题出在宿主 g++ 编构建工具那一步。

解决：给CXX加上-std=gnu++98 -fpermissive，让宿主 g++ 退回老标准并放宽检查。如果还是过不去，先只做 C 前端：--enable-languages=c，把 C++ 留到工具链跑通之后再补。做交叉时我通常第一阶段就只要 C，等 sysroot 齐了再回来加 C++。

5.5 装完的编译器编出的程序在目标机上跑不起来

现象：本机测试全过，二进制拷到目标板上一执行就报GLIBC_2.34 not found或者直接段错误。

原因：编译过程中混用了宿主的 glibc 头文件。典型是交叉构建时--with-headers指到了/usr/include，或者 sysroot 里只有头文件没有对应的库，链接时静态库是从宿主路径找到的。

解决：检查-print-search-dirs的输出里有没有宿主路径混入，确认 sysroot 下usr/lib里的libc.so、crt1.o确实存在且是目标架构。用file /opt/arm-sysroot/usr/lib/libc.so.6确认架构。对老设备，最终产物一律-static链接，把运行时依赖降到零，这是最省心的后悔药。

6. 把这次构建固化成脚本：校验清单与版本锁

调通一次不算本事，半年后还能原样复现才算。我现在的做法是把整条链路写成带set -euo pipefail的脚本，参数全部走环境变量，构建前先校验前置条件，构建后跑一遍固定自检。下面这段是骨架，可以直接改成你需要的形态：

#!/usr/bin/env bash set -euo pipefail SRC=${SRC:-/opt/src/gcc-3.3.6} PREFIX=${PREFIX:-/opt/toolchain/gcc-3.3.6} BUILD=${BUILD:-/opt/build/gcc-3.3.6} JOBS=${JOBS:-$(nproc)} # 前置检查：缺一样就直接退出，不要带着半成品环境往下跑 for t in gcc make as ld; do command -v "$t" >/dev/null || { echo "missing: $t"; exit 1; } done rm -rf "$BUILD" && mkdir -p "$BUILD" && cd "$BUILD" CC="gcc -std=gnu89 -fcommon -fno-stack-protector -fno-pie" \ CXX="g++ -std=gnu++98 -fpermissive -fno-stack-protector -fno-pie" \ "$SRC/configure" \ --prefix="$PREFIX" \ --build="$(uname -m)-pc-linux-gnu" \ --enable-languages=c,c++ \ --disable-bootstrap --disable-nls --disable-shared --disable-libgcj \ 2>&1 | tee configure.log make -j"$JOBS" MAKEINFO=true 2>&1 | tee build.log make install # 后置自检：任何一条不过就非零退出 "$PREFIX/bin/gcc" -dumpmachine printf 'int main(void){return 0;}\n' > /tmp/t.c "$PREFIX/bin/gcc" /tmp/t.c -o /tmp/t && /tmp/t

脚本里两个设计点值得说：前置检查那一段用command -v逐个探，比在一堆报错里找“为什么 as 找不到”高效得多；后置自检放在脚本里而不是文档里，是因为人会忘，脚本不会。

配套的产物校验清单我贴在下面，每次装完对一遍，缺项就说明哪一步没走完整：

这套东西我是被逼出来的。早年给某实验室复现一套老固件构建，现场调了六个小时才跑通，回来后没留脚本，四个月后同型号设备再来一台，从头又踩了一遍一模一样的坑，包括那个-fcommon。从那以后我每次上老工具链，第一件事就是把命令写进脚本、把自检写进脚本、把镜像和版本号写进 README，宁愿多花二十分钟，也不赌自己的记性。希望帮到你。

本文还有配套的精品资源，点击获取