简介GCC 3.3.6 源码压缩包面向从事嵌入式开发、操作系统移植与交叉编译工具链构建的工程师及高年级学习者用于在宿主机上定制生成面向目标架构的编译器套件。包内共约2000个文件压缩后约30.03MB以C语言源码约7800个.c为主体辅以C、Java、Fortran、Ada等语言前端的实现与头文件并包含configure配置脚本、Makefile.in模板、.md机器描述文件、.texi技术文档及成体系的测试用例完整覆盖预处理器、编译器、汇编器与链接器的构建素材。解压后得到gcc-3.3.6目录其中按语言前端、目标平台配置、文档与测试分块组织便于按目标架构裁剪语言组件与运行时库理解GCC内部结构与交叉编译配置流程。已有221人学习下载适合需要复现经典工具链、查阅一手源码的读者参考。1. 为什么还要摸 gcc-3.3.6新编译器编不过老代码这件事接手一份 2004 年前后的遗留代码源码里全是 KR 风格函数定义、隐式 int、register变量、iostream.h这种老式 C 头文件用现在的 GCC 13/14 一编几十条 error 糊脸CFLAGS 里加-fpermissive也压不住。这时候 gcc-3.3.6.tar.gz 就是一台时间机器。它是 GCC 3.3 系列的最后一个维护版本默认 C 标准是 gnu89C 默认 C98libstdc 的 soname 还停在libstdc.so.5和现代系统完全是两套脾气。它解决的问题很窄让那些写于二十年前、只认老编译器的 C/C 代码重新编得过。适合复现遗留项目、补老工具链、做编译器行为对比的人日常新项目别碰它它是考古工具不是生产力主力。2. 拆包与构建环境configure 之前先把地基垫平2.1 包里有什么真正要装的依赖是哪几个解包之后先别急着configure花两分钟看一眼目录结构。gcc-3.3.6 顶层有configure、gcc/C 前端、cp/C 前端、libstdc-v3/、boehm-gc/、libjava/、zlib/这些目录。release tar 包的一个好处是bison/flex 生成的 parser 文件已经打在包里了只要不改.y文件就不需要额外装 bison 和 flex。这一点和从版本库直接 checkout 源码完全不同也是很多人误以为要装一堆构建工具的原因。真正需要的依赖只有宿主 C 编译器、make、binutilsas/ld和 glibc 开发头文件。GMP 和 MPFR 不是必需项——这两个库变成 GCC 的硬依赖是 4.3 之后的事3.3.6 时代的源码还没这么讲究。texinfo 属于“有更好、没有也能绕”的类别后面避坑章会专门讲怎么跳过它。# 解包并确认顶层结构 tar -xzf gcc-3.3.6.tar.gz cd gcc-3.3.6 ls -1 | head -30 # 确认 release 包自带生成的 parser不需要 bison/flex ls -l gcc/c-parse.c gcc/c-parse.y 2/dev/null上面第二条命令是在验证“包是不是完整的 release 包”。如果c-parse.c存在说明 parser 已生成可以跳过 bison如果只有.y没有.c那说明拿到的是开发树得先把 bison/flex 补齐。这个判断能省掉不少无头苍蝇式的依赖安装。依赖项是否必需说明宿主 gcc/g必需用来编 stage1版本越老越省事make必需GNU make3.80 以上即可binutilsas/ld必需链接阶段要用太新也可能出问题glibc-devel必需提供系统头文件和 crt 对象texinfo可选只影响 info 文档可MAKEINFOtrue跳过bison/flex通常不需要release 包已生成 parserGMP/MPFR不需要4.3 之后才成为硬依赖2.2 宿主 GCC 别选太新的这是成功率的第一变量3.3.6 的源码是 2004 年的 C 代码用 gnu89 写成隐式函数声明、隐式 int、旧式参数列表到处都是。现代 GCC 从 14 开始把implicit-function-declaration从 warning 提升为默认 errorCFLAGS 里塞-stdgnu89也救不回来因为新 frontend 的严格性不只看标准开关。我自己的经验分布是宿主用 GCC 4.8 到 5.4成功率最高GCC 7 到 9 要加不少 workaroundGCC 12 以上基本要打补丁才走得通。如果手头机器只有新 GCC优先考虑在容器里跑一个老发行版镜像而不是在宿主机上硬扛。这不是偷懒是把“编译器版本”这个变量先固定住后面排查才有基准。选定宿主之后用CC和CXX两个环境变量把它传给顶层 configure不设的话默认就用系统gcc。# 看当前宿主编译器 gcc --version | head -1 # 如果系统装了多版本挑一个老一点的 ls /usr/bin/gcc-* 2/dev/null export CC/usr/bin/gcc-4.8 export CXX/usr/bin/g-4.8CC/CXX会被顶层 configure 继承并一路传到 stage1 的编译命令里。这两个变量设错后面所有阶段都会跟着错所以动手前先用$CC --version确认一遍别嫌麻烦。提示不要在宿主编译器版本上抱侥幸心理。3.3.6 编不过的第一大原因就是宿主太新先把这个变量控制住再谈其他参数。2.3 configure 参数逐项拆砍掉不需要的前端GCC 官方推荐 out-of-tree build也就是在源码目录外单独建一个 build 目录。这样做的好处很实际编译失败时整个 build 目录一删就干净了源码树不会被中间文件污染也不会出现“改过 configure 但旧目标文件还在”的玄学问题。参数上我一般这么配--prefix指到独立目录绝不覆盖系统/usr--enable-languagesc,c只编 C 和 C把 java、fortran、objc 全部砍掉。3.3.6 的 libjava 依赖老版本 boehm-gc 和一堆已经消失的头文件在现代系统上几乎必挂留着它只是给自己增加失败面。--disable-multilib用来避免 64 位主机上找不到 32 位 crt 对象--disable-nls省掉 gettext 依赖--disable-checking关闭编译器内部的额外一致性检查release 模式默认就偏松显式写上是为了让行为确定。mkdir -p /opt/src/gcc-build-3.3.6 cd /opt/src/gcc-build-3.3.6 ../gcc-3.3.6/configure \ --prefix/opt/gcc-3.3.6 \ --enable-languagesc,c \ --disable-multilib \ --disable-nls \ --disable-checking \ 21 | tee configure.logtee configure.log不是装饰configure 的输出里有大量探测结果后面编译失败时经常要回头查“某个头文件当时到底检测到没有”。把日志留下来等于给自己留了一颗后悔药。参数作用不写会怎样--prefix安装到独立目录默认装进/usr/local覆盖系统工具链--enable-languages限定前端默认全开java/fortran 大概率编译失败--disable-multilib不生成 32 位库64 位主机上链接报cannot find crti.o--disable-nls关闭国际化多一层 gettext 依赖和潜在报错--disable-checking关闭内部检查编译更慢行为随版本浮动3. bootstrap 三阶段编译make 在跑什么、卡在哪一步3.1 stage1、stage2、stage3 的分工GCC 的默认构建方式是自举bootstrap分三个阶段。stage1 用宿主编译器编译 GCC 源码产出一个叫stage1/xgcc的编译器stage2 用这个xgcc再编译一遍同一份源码产出stage2/xgccstage3 再用 stage2 的产物编第三遍最后比较 stage2 和 stage3 生成的目标文件是否一致。一致说明新编译器能正确编译自己自举通过不一致就是Bootstrap comparison failure。这个过程很慢但它验证的是编译器本身的正确性。调试阶段可以用--disable-bootstrap先跑通单阶段拿到一个能用的二进制正式交付或要求可复现时还是建议保留完整自举。时间账大概是单核三阶段 30 到 60 分钟视机器而定make -j4能压到 5 到 15 分钟。cd /opt/src/gcc-build-3.3.6 # 记录起始时间方便判断是慢还是卡死 date make -j4 21 | tee build.log-j4是稳妥值不是随便定的。老代码在并行编译时内存峰值比想象中高-j32很容易把 cc1 进程送进 OOM killer。后面避坑章会专门讲这个现象。3.2 日志里该盯哪几行编译期间另开一个终端tail -f build.log盯几个关键标记就够了Configuring in ...表示进入某个子目录stage1/xgcc、stage2/xgcc是阶段切换的信号Comparing stages 2 and 3表示进入最后比对Bootstrap comparison failure!则是自举失败的明确信号。大部分时间日志刷得很快真正需要停下来看的是出现make[3]: ***的那几行。中断之后不要从头翻日志用 grep 定位最后一个错误块再看它前面八十行基本就能判断是头文件缺失、语法不兼容还是链接失败。# 定位最后一个 make 错误 grep -n ^make.*\*\*\* build.log | tail -5 # 看错误前后的上下文 tail -80 build.loggrep只负责找位置tail -80负责给上下文。两个命令配合比在几千行日志里肉眼扫描高效得多。如果错误出现在libstdc-v3目录大概率是 glibc 头文件不兼容如果出现在gcc/目录且报隐式声明那就是宿主编译器太新。3.3 中断、续跑与彻底重来make本身支持续跑只要 configure 参数和宿主环境没变重新敲make会从断点继续。但有两种情况必须删掉 build 目录重来一是改过 configure 参数二是换过CC/CXX。原因很简单stage1 和 stage2 用的编译器不一致时自举比对必然失败而且报错信息往往指向一个和根因无关的文件特别迷惑。判断要不要重来看 build 目录里有没有完整的stage1产物。如果只是某个子目录挂了、stage1 还在可以进子目录单独make试试但 3.3.6 的子目录依赖链比较绕我一般直接删了重来省下的排查时间比重新编译的时间更值钱。# 彻底重来删 build 目录保留源码和 configure.log 备查 cd /opt/src rm -rf gcc-build-3.3.6 mkdir gcc-build-3.3.6 cd gcc-build-3.3.6 ../gcc-3.3.6/configure \ --prefix/opt/gcc-3.3.6 \ --enable-languagesc,c \ --disable-multilib \ --disable-nls \ --disable-checking \ 21 | tee configure.log重来之前把旧的configure.log改名存一下万一新一次配置行为和上次不一样还能对比。这个习惯在排查“为什么同一份源码两次编译结果不同”时特别有用。4. 安装、路径隔离与多版本共存别让 .so.5 污染系统4.1 make install 之后的目录长什么样make install跑完先别急着写代码花几分钟确认目录布局。3.3.6 的库目录是lib/gcc-lib/target/3.3.6/不是新版本那种lib/gcc/。这个差异在写 rpath、做打包、配 CMake toolchain 文件时都会咬人。C 头文件在include/c/3.3.6/下和现代 GCC 的include/c/13/是同一套思路只是路径前缀不同。make install # 确认二进制和库的落点 ls /opt/gcc-3.3.6/bin find /opt/gcc-3.3.6/lib -maxdepth 3 -name libstdc* ls /opt/gcc-3.3.6/include/c/find那一条是为了确认libstdc.so.5到底在哪一层。不同 target triplet 下路径会略有差异提前记下来后面配运行时路径就不用猜。路径内容/opt/gcc-3.3.6/bin/gccC 编译器驱动/opt/gcc-3.3.6/bin/gC 编译器驱动/opt/gcc-3.3.6/lib/gcc-lib/target/3.3.6/cc1、cc1plus、libgcc/opt/gcc-3.3.6/lib/libstdc.so.5C 运行库/opt/gcc-3.3.6/include/c/3.3.6/C 标准库头文件4.2 运行时库libstdc.so.5 和系统 .so.6 的隔离GCC 3.3 的 libstdc soname 是libstdc.so.5现代系统是.so.6。两者 soname 不同不会互相覆盖这是好事但用 3.3.6 编出来的 C 程序运行时必须能找到.so.5否则启动就报error while loading shared libraries。常见做法有两种在调用脚本里显式设LD_LIBRARY_PATH或者链接时加-Wl,-rpath,/opt/gcc-3.3.6/lib把路径烧进二进制。# 用 3.3.6 编一个 C 程序并检查依赖 /opt/gcc-3.3.6/bin/g -o demo demo.cpp ldd demo | grep libstdc # 如果运行时找不到 .so.5临时补路径 LD_LIBRARY_PATH/opt/gcc-3.3.6/lib ./demoldd那一步是在确认二进制到底链了哪个 soname。如果显示libstdc.so.6说明g实际调到的还是系统编译器得回头检查 PATH 顺序。注意不要把/opt/gcc-3.3.6/lib加进全局LD_LIBRARY_PATH或/etc/ld.so.conf。老库和新库的符号版本混在一起系统里其他 C 程序可能出现难以定位的加载问题。按需在脚本里设是最稳的做法。4.3 三种共存方式怎么选和系统 GCC 共存常见做法有三类。第一类是独立 prefix 加 PATH 切换最简单用时source一个脚本退出 shell 就恢复缺点是容易忘换个终端窗口就找不到编译器。第二类是 configure 时加--program-suffix-3.3.6生成gcc-3.3.6、g-3.3.6这样带后缀的名字可以和系统 gcc 长期并存这个参数在 3.3.6 上能用但装完要逐个确认bin/下的名字别假设所有子目录行为一致。第三类是容器或虚拟机隔离最干净适合团队复现代价是重。我本地习惯用第一类配一个env-3.3.6.sh需要时 source 一下团队交付用第三类把整个工具链封进镜像谁复现都是同一套环境。# env-3.3.6.sh export GCC336_HOME/opt/gcc-3.3.6 export PATH$GCC336_HOME/bin:$PATH export LD_LIBRARY_PATH$GCC336_HOME/lib:$LD_LIBRARY_PATH export CC$GCC336_HOME/bin/gcc export CXX$GCC336_HOME/bin/g这个脚本把 PATH、运行时库路径和 CC/CXX 一次性固定住。source env-3.3.6.sh之后gcc --version应该显示 3.3.6新开一个 shell 就自动回到系统默认不会把环境搞混。方式隔离程度适合场景主要代价独立 prefix PATH中个人本地复现换终端需重新 source--program-suffix中长期共存、脚本调用装完要核对二进制名容器/虚拟机高团队交付、CI 复现镜像体积和启动开销5. 五类高频翻车现场与排查从隐式声明到 OOM5.1 隐式函数声明直接报 error现象编译刚开始不久就出现error: implicit declaration of function gets或者error: unknown type name uint8一屏接一屏。原因现代 GCC 默认标准变严GCC 14 起隐式声明默认就是 error-fpermissive在 C 模式下不是万能药很多诊断压不下去。解决首选换老宿主4.8/5.4次选在 CFLAGS 里放宽诊断但只能压住一部分压不住的还得打补丁或改源码。# 兜底方案放宽诊断不保证全部编过 CFLAGS-stdgnu89 -fpermissive -Wno-errorimplicit-function-declaration \ CXXFLAGS-stdgnu98 -fpermissive \ ../gcc-3.3.6/configure \ --prefix/opt/gcc-3.3.6 \ --enable-languagesc,c \ --disable-multilib这段配置只是把“硬 error”降级成“warning”让编译能继续往下走。它救不了类型定义缺失这类结构性问题所以看到仍然报错时不要在这条路上死磕换宿主才是正解。5.2 makeinfo 报错或干脆缺失现象编译到文档目录时报makeinfo: command not found或者装了新版 texinfo 之后报unknown command指向.texi文件里的某一行。原因要么没装 texinfo要么装的是 7.x语法和 2004 年的.texi不兼容。解决直接MAKEINFOtrue跳过文档生成。info 文档不是运行必需品编译器和库能装出来就行。# 跳过 info 文档生成只编二进制和库 make MAKEINFOtrue -j4 make MAKEINFOtrue installMAKEINFOtrue相当于把 makeinfo 替换成/bin/true所有文档目标都“成功”但不产出文件。这个技巧对老源码包普遍适用不止 3.3.6。5.3 libstdc-v3 和新版 glibc 头文件打架现象C 前端编完了卡在libstdc-v3报isnan was not declared in this scope、strtold is not a member of std或者struct sigaltstack重定义。原因2004 年的 libstdc 源码假设老 glibc 用宏提供isnan/isinf现代 glibc 改成了函数sigaltstack的结构体定义也变了。解决如果项目只用 C直接--enable-languagesc砍掉 C 前端绕开整块如果必须用 C就在容器里换老发行版或者找社区补丁。5.4 64 位主机上的 crti.o 与 multilib现象链接阶段报cannot find crti.o或cannot find -lc。原因默认 target 是 x86_64链接时需要 32 位运行库而系统没装 multilib 开发包。解决加--disable-multilib不生成 32 位库确实需要 32 位产物的装 multilib 开发包或者用--targeti686-linux-gnu走交叉编译路线。5.5 并行编译把内存打爆现象make -j32跑一阵子进程被 killdmesg里能看到 oom-killer 记录或者直接报cc1: out of memory。原因stage2/3 的 cc1 在优化大文件时内存峰值很高老代码没做内存友好处理并行度一高就撞墙。解决降到-j4或-j$(nproc/2)加 swap单核慢慢跑。用编译时间换稳定这笔账在复现场景里通常划算。这五类问题基本覆盖了 3.3.6 在现代系统上的主要失败面。排查顺序建议按“宿主版本 → 日志定位 → 前端裁剪 → 并行度”走从外到内别一上来就改源码。6. 验证与进阶拿一段 KR 老代码把 3.3.6 钉死装完不验证等于没装。最直接的验证方式不是看gcc -v而是拿一段典型的老代码真编一遍。下面这段是 2004 年前后常见的 KR 风格参数类型写在参数表后面现代 C 标准早就把它归到历史垃圾堆里但 3.3.6 默认的 gnu89 完全接受。/* legacy.c —— 典型的 KR 风格 C 代码 */ #include stdio.h /* 参数类型在参数表之后声明 */ int add(a, b) int a; int b; { return a b; } int main() { printf(%d\n, add(1, 2)); return 0; }用两套编译器分别编一次对比行为差异# 现代 GCC 在严格标准下会告警甚至报错 gcc -stdc17 -Werror legacy.c -o legacy_new 21 | head -5 # 用 3.3.6 直接编 /opt/gcc-3.3.6/bin/gcc -o legacy_336 legacy.c ./legacy_336 # 确认版本 /opt/gcc-3.3.6/bin/gcc -v 21 | grep gcc versionlegacy_336能正常输出3说明编译器驱动、cc1、汇编器和链接器整条链路都通了。如果这一步失败问题一定在安装或运行时库路径上而不是源码。进阶用法是把编译环境固化成 Makefile 片段或 wrapper 脚本团队里谁复现都用同一套变量避免“我这儿能编你那儿不能编”。更细一点可以做一张默认行为对照表写清两套编译器的差异贴进项目 README后来人一看就知道哪些语法不能碰。行为项GCC 3.3.6现代 GCC默认 C 标准gnu89gnu17 / gnu23默认 C 标准C98C17 及以上本文还有配套的精品资源点击获取