简介：gcc-3.3.6.tar.gz 是 GNU 编译器集合 3.3.6 版本的源码归档包，面向从事嵌入式开发、操作系统移植与交叉编译工具链构建的开发者，尤其适合需要为特定目标架构定制编译器的中高级工程师。包内共约 2000 个文件，以 C 源码（7828 个）、Java 源码（2027 个）、头文件（1243 个）为主，另含汇编、C++、Fortran、Makefile 模板、配置脚本及文档等，整体约 30.03MB，覆盖编译器前端、后端与运行时库的完整实现。解压后得到 gcc-3.3.6 目录，包含 configure 配置脚本、Makefile.in 模板、README/INSTALL 文档、测试用例以及 cpp、gcc、g++、as、ld 等工具源码，便于按目标架构定制编译选项并逐步构建交叉工具链。目前已有 221 人学习下载，适合希望深入理解编译原理、动手搭建交叉编译环境的读者参考。
1. 老编译器为什么还有人惦记：从 gcc-3.3.6.tar.gz 说起
如果你在维护一套十几年前甚至二十年前的老代码，或者要给一块早已停产的芯片重新编译固件，你大概率会在某个时刻撞上gcc-3.3.6.tar.gz这个压缩包。它不是最新的编译器，恰恰相反，它是 2004 年前后发布的 GCC 3 系列最后一个稳定版本之一。今天很多人第一次见到它，不是因为想学它，而是因为某个老项目的构建脚本里写死了gcc-3.3，或者某段汇编、某个内联语法只有这个版本才认。这时候你面对的不是「要不要升级」，而是「怎么让它在今天的机器上跑起来」。
这篇文章讲的就是这件事：拿到gcc-3.3.6.tar.gz之后，怎么从源码把它编译出来、装到哪个位置、需要哪些依赖、会遇到哪些坑。适合两类人：一类是被老项目绑住、必须复现当年构建环境的工程师；另一类是想搞清楚 GCC 自举（bootstrap）流程、拿老版本练手的同学。我不会假装这是官方文档，下面写的都是这类老编译器在真实机器上编译时最常走的路子和最容易翻车的地方。
2. 编译前的环境准备：依赖、目录与工具链选择
老版本 GCC 对现代系统的「不友好」是从配置阶段就开始的，很多失败不是代码问题，而是环境没铺好。这一章先把地基打牢，后面编译才不会反复推倒重来。
2.1 为什么老 GCC 在现代发行版上第一步就卡住
GCC 3.3.6 发布于 2004 年，那个年代的 C 标准、头文件布局、链接器行为和今天差别很大。现代发行版默认用 GCC 12/13 甚至更高版本，glibc 也早就不是当年的样子。直接用系统自带的新编译器去编译老 GCC，最常见的现象是：配置脚本能过，但一进make就报一堆语法错误或者类型不匹配。原因不玄学——老代码里有些写法在新标准下已经非法，或者依赖了当年头文件里才有的宏。
所以核心思路是：用一个「中间版本」的编译器来编译 gcc-3.3.6。实践中比较稳的组合是先用系统自带的 GCC 编译一个 GCC 4.x 系列（比如 4.8 或 4.9），再用这个 4.x 去编译 3.3.6。如果嫌麻烦，也可以直接找发行版里还保留的gcc-4.x包。这一步不是必须绝对，但能省掉大量「改源码适配新编译器」的功夫。
另一个必须提前确认的是GMP、MPFR、MPC这三个数学库。GCC 4.x 之后把它们作为独立依赖，而 GCC 3.3.6 时代它们还没被强制要求，但如果你用较新的构建环境，配置脚本可能会去找它们。老版本 GCC 的configure对这三个库的检测逻辑比较粗糙，缺了会直接报错。建议提前装好开发包，或者把源码放到 GCC 源码树里让它自动编译。
2.2 依赖清单与目录规划
在动手之前，先把要装的东西列清楚。下面这张表是我一般会提前确认的：
| 依赖项 | 作用 | 检查方式 |
|---|---|---|
| 中间版本 GCC（4.x） | 编译 gcc-3.3.6 的宿主编译器 | gcc-4.8 --version |
| GMP / MPFR / MPC | 高精度数学运算，部分配置会检测 | ldconfig -p | grep gmp |
| make / binutils | 构建与汇编链接 | make --version、ld --version |
| 开发头文件 | glibc-devel 等 | 编译一个 hello.c 验证 |
| 足够的磁盘空间 | 源码 + 构建目录 + 安装目录 | 建议预留 3GB 以上 |
目录规划上，我强烈建议源码目录、构建目录、安装目录三者分开。GCC 官方也推荐 out-of-tree 构建，原因是源码树里会生成大量中间文件，混在一起后想重新配置会很麻烦。典型布局：
# 假设压缩包放在 /opt/src 下 mkdir -p /opt/src/gcc-build-3.3.6 mkdir -p /opt/gcc-3.3.6 cd /opt/src tar -xzf gcc-3.3.6.tar.gz解压后得到gcc-3.3.6源码目录，构建目录单独建，安装目录也单独指定。这样后面想删掉重来，直接删构建目录就行，源码不受影响。
2.3 配置命令与关键参数说明
进入构建目录后执行configure。这一步的参数决定了后面编译出来的编译器长什么样，几个关键项必须说清楚：
cd /opt/src/gcc-build-3.3.6 ../gcc-3.3.6/configure \ --prefix=/opt/gcc-3.3.6 \ --enable-languages=c,c++ \ --disable-multilib \ --disable-nls \ --with-system-zlib逐项解释：
--prefix=/opt/gcc-3.3.6：安装路径。不要装到/usr覆盖系统编译器，否则系统工具链可能直接坏掉，这是血泪经验。--enable-languages=c,c++：只编 C 和 C++。老版本编 Fortran、Java 等前端耗时极长且容易失败，除非确实需要，否则别开。--disable-multilib：只生成 64 位（或只生成 32 位）库，避免同时构建两套运行时。现代机器上 multilib 经常因为缺 32 位库而失败。--disable-nls：关掉本地化消息，减少依赖，编译更快。--with-system-zlib：用系统 zlib，避免老版本自带 zlib 在新系统上编译报错。
配置阶段如果报错，先看config.log，里面会写清楚是哪个检查失败。常见的是找不到 GMP/MPFR，或者宿主编译器版本太新导致某个测试程序编译不过。
3. 从 make 到安装：把 gcc-3.3.6 真正跑起来
配置过了只是拿到入场券，真正耗时的是编译。这一章讲编译流程、自举机制，以及怎么验证装出来的编译器确实能用。
3.1 bootstrap 自举流程与耗时预期
GCC 的编译不是简单地把源码编成二进制，它有一个三阶段自举（bootstrap）过程：
- stage1：用宿主编译器（比如 gcc-4.8）编译出一套 GCC 3.3.6 的编译器。
- stage2：用 stage1 编出来的编译器再编译一遍源码。
- stage3：用 stage2 再编译一遍，然后比较 stage2 和 stage3 的产物是否一致。
这个机制的目的是验证编译器能正确编译自己。对 gcc-3.3.6 来说，在单核虚拟机上跑完整个 bootstrap 可能要几个小时，多核机器上可以用make -jN加速，但注意老版本 GCC 的 Makefile 对并行编译支持不算完美，-j开太大偶尔会出竞态问题。我一般用-j4或-j8，再高收益不明显。
# 在构建目录下执行，N 根据 CPU 核数调整 make -j4如果中途失败，先别急着重跑。看错误发生在哪个阶段：stage1 失败通常是宿主编译器或依赖问题；stage2/stage3 失败可能是源码本身在自举时暴露了问题。把出错目录下的.log文件翻出来，比盲目重试有用得多。
3.2 安装与多版本共存的处理
编译成功后执行安装：
make install装完之后，/opt/gcc-3.3.6/bin下会有gcc、g++等可执行文件。但这里有个坑：不要直接把这个路径加到全局 PATH 最前面，否则系统里其他构建任务会莫名其妙用上老编译器，引发一堆难以排查的问题。正确做法是用的时候显式指定，或者写一个包装脚本：
# 临时使用老编译器编译某个项目 export CC=/opt/gcc-3.3.6/bin/gcc export CXX=/opt/gcc-3.3.6/bin/g++ ./configure && make如果确实需要频繁切换，可以用update-alternatives或者自己写一个gcc-3.3.6的 wrapper，把--prefix下的工具链单独暴露出来，而不是覆盖gcc这个名字。
3.3 验证安装：编译一个最小程序并检查版本
装完必须验证，不然你可能在用一个「看起来装好了但实际链接的是系统库」的假编译器。写一个最小程序：
/* hello.c - 验证 gcc-3.3.6 能否正常编译链接 */ #include <stdio.h> int main(void) { printf("built with gcc %s\n", __VERSION__); return 0; }编译并运行：
/opt/gcc-3.3.6/bin/gcc hello.c -o hello ./hello如果输出里能看到3.3.6字样，说明编译器本身工作正常。再检查一下它默认链接的库路径：
/opt/gcc-3.3.6/bin/gcc -v hello.c -o hello 2>&1 | grep -E "gcc version|collect2"这里要确认collect2和链接器用的是老工具链自己的路径，而不是系统路径。如果发现它偷偷用了系统的ld，那在编译老项目时可能因为链接器行为差异出问题。必要时用-B参数强制指定工具链前缀。
4. 避坑与排查：老 GCC 编译时最容易翻车的五件事
这一章是我自己踩过、也见别人踩过的坑，按「现象 → 原因 → 解决」写。老编译器的问题往往不是单一原因，排查时要有耐心。
4.1 配置阶段报 “C compiler cannot create executables”
现象：执行configure没多久就退出，config.log里写着C compiler cannot create executables。
原因：宿主编译器本身有问题，或者缺少基本的开发头文件/库。也可能是--prefix路径权限不对，配置脚本写测试文件失败。
解决：先手动用宿主编译器编译一个 hello.c，确认它能正常出可执行文件。如果宿主没问题，检查config.log里具体是哪条命令失败，常见的是缺libc-dev或者临时目录不可写。把TMPDIR指到一个有权限的目录再试。
4.2 stage1 编译到一半报大量语法错误
现象：make跑了一段时间后，突然出现成片的error: expected '=' ...或error: 'struct' has no member named ...。
原因：宿主编译器太新，老 GCC 源码里的某些写法在新标准下不合法。比如旧式函数定义、隐式类型转换、或者依赖了已被移除的头文件宏。
解决：换用 GCC 4.x 作为宿主，或者在配置时加上--disable-werror并适当降低优化级别。如果错误集中在某个文件，可以单独给那个文件加-std=gnu89之类的旧标准选项。实在不行就手动改源码，但改动要记录，方便后面复现。
4.3 链接阶段报 “cannot find -lgcc_s” 或类似库缺失
现象：编译快结束时，链接测试程序报找不到libgcc_s或其他运行时库。
原因：老版本 GCC 的库搜索路径和新系统的库布局不匹配，或者 multilib 配置导致它去找一个不存在的 32 位库。
解决：确认配置时加了--disable-multilib。如果还报错，检查LD_LIBRARY_PATH是否被污染，临时清空再试。也可以在configure时加--with-gnu-ld明确指定用 GNU 链接器。
4.4 安装后编译老项目，报 “unrecognized command line option”
现象：用装好的 gcc-3.3.6 去编译目标项目，结果报某个选项不认识。
原因：你调用的可能不是/opt/gcc-3.3.6/bin/gcc，而是系统 PATH 里的新 GCC。或者项目的 Makefile 里写死了gcc，没有用CC变量。
解决：用which gcc和gcc --version确认当前用的是哪个。在项目构建时显式传CC=/opt/gcc-3.3.6/bin/gcc。如果 Makefile 写死了，可以用make CC=...覆盖，或者临时改 PATH 但记得改回来。
4.5 编译出来的程序运行时报 “GLIBC version not found”
现象：用老 GCC 编出来的程序，在另一台机器上跑不起来，提示 glibc 版本不匹配。
原因：老 GCC 链接的是它自己那套运行时，但目标机器上的 glibc 可能更新或更旧，符号版本对不上。
解决：如果程序要在特定环境运行，最好在那个环境里编译，或者用静态链接（-static）减少对系统库的依赖。但静态链接也有代价，比如体积变大、某些功能受限。另一种做法是把老 GCC 的运行时库一起打包，运行时用LD_LIBRARY_PATH指定。
5. 进阶技巧：让老编译器在现代工作流里少添乱
把 gcc-3.3.6 装好只是第一步，真正难的是让它和今天的开发流程共存。这一章讲几个我常用的技巧，能减少很多重复劳动。
5.1 用容器隔离老工具链
最省心的办法是把老编译器和它的依赖全部封在一个容器镜像里。这样宿主系统怎么升级都不影响它，团队里其他人也能直接复用。Dockerfile 大致长这样：
# 基于一个较老的发行版镜像，减少兼容性问题 FROM debian:7 # 安装中间版本编译器和依赖 RUN apt-get update && apt-get install -y \ gcc-4.7 g++-4.7 make binutils \ libgmp-dev libmpfr-dev libmpc-dev \ && rm -rf /var/lib/apt/lists/* # 复制并编译 gcc-3.3.6 COPY gcc-3.3.6.tar.gz /opt/src/ RUN cd /opt/src && tar -xzf gcc-3.3.6.tar.gz \ && mkdir build && cd build \ && ../gcc-3.3.6/configure --prefix=/opt/gcc-3.3.6 \ --enable-languages=c,c++ --disable-multilib --disable-nls \ && make -j4 && make install ENV PATH=/opt/gcc-3.3.6/bin:$PATH这个做法的好处是环境完全可复现，坏处是镜像体积不小。如果只是偶尔用，可以不做成镜像，而是写一个chroot或者用systemd-nspawn起一个轻量环境。
5.2 用 wrapper 脚本固定编译参数
老项目往往需要一堆特定的编译选项，每次手敲容易漏。写一个 wrapper 把常用参数固化下来：
#!/bin/bash # gcc336-wrapper.sh - 固定老项目常用编译参数 GCC_PREFIX=/opt/gcc-3.3.6 exec ${GCC_PREFIX}/bin/gcc \ -std=gnu89 \ -fno-strict-aliasing \ -I${GCC_PREFIX}/include \ "$@"把这个脚本放到 PATH 里，项目里用CC=gcc336-wrapper.sh即可。参数不是固定的，根据项目实际需要调整。关键是让「用老编译器」这件事变得可重复，而不是每次靠记忆。
5.3 验证老编译器产物的兼容性
最后一步是确认编出来的东西真的能用。除了跑单元测试，我一般会做两件事：一是用file和ldd看二进制的架构和依赖库；二是和目标运行环境做一次实际部署测试。下面这个小脚本可以快速检查：
#!/bin/bash # check_binary.sh - 检查老编译器产物的基本信息 BIN=$1 echo "=== file ===" file "$BIN" echo "=== ldd ===" ldd "$BIN" echo "=== 符号版本 ===" objdump -T "$BIN" | grep GLIBC | head -20如果ldd显示依赖了目标环境没有的库，或者objdump里的 GLIBC 版本高于目标环境，那就得考虑静态链接或者换编译环境。这一步不做，后面部署时大概率要返工。
我自己在这类老编译器上最大的教训是：不要相信「编译通过就等于能用」。曾经有一次 stage3 都跑完了，装出来的编译器也能编 hello world，但一编真实项目就链接失败，最后发现是collect2调用的链接器路径不对。从那以后，我每次装完老工具链，都会拿一个真实的小项目跑一遍完整构建，而不是只测 hello world。希望这些经验能帮到你，少走点弯路。
本文还有配套的精品资源，点击获取
