GCC 3.3.6 老编译器复现与交叉工具链构建避坑指南

简介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接受 KR 风格的函数定义和隐式函数声明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 标准会直接拒绝 KR 风格的函数定义。不是说不能用新宿主而是你得手动把这几项掰回去后面第三章会给具体开关。第二样是 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 CCgcc -stdgnu89 -fcommon -fno-stack-protector -fno-pie \ CXXg -stdgnu98 -fpermissive -fno-stack-protector -fno-pie \ /opt/src/gcc-3.3.6/configure \ --prefix/opt/toolchain/gcc-3.3.6 \ --buildx86_64-pc-linux-gnu \ --enable-languagesc,c \ --disable-bootstrap \ --disable-nls \ --disable-shared \ --disable-libgcj \ --enable-threadsposix \ 21 | tee configure.log第一行把兼容开关塞进CC和CXX环境变量这是关键。-stdgnu89让编译器和 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-languagesc,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 -20configure: error: C compiler cannot create executables是最常见的一条原因九成在上面那几个兼容开关没加对或者宿主的头文件路径有问题config.log里能直接看到是哪个-I路径导致的。3.2 make并行、日志与第一次失败怎么读configure 通过之后就可以开编。我习惯把输出全量落盘因为失败点经常在几千行之前make -j$(nproc) 21 | 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-errorimplicit-function-declaration或者确认-stdgnu89真的传进去了。判断开关有没有传进去最土也最有效的办法是看 make 打印出来的实际编译命令行搜一个具体文件名grep -m 3 gcc .*insn-emit build.log如果命令行里看不到-stdgnu89说明某个 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:$PATH4. 交叉工具链把 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 CCgcc -stdgnu89 -fcommon -fno-pie \ /opt/src/gcc-3.3.6/configure \ --prefix/opt/toolchain/arm-3.3.6 \ --buildx86_64-pc-linux-gnu \ --hostx86_64-pc-linux-gnu \ --targetarm-linux-gnueabi \ --with-sysroot/opt/arm-sysroot \ --without-headers \ --with-newlib \ --enable-languagesc \ --disable-shared \ --disable-nls \ 21 | tee configure-stage1.log make -j$(nproc) all-gcc 21 | 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 NEEDEDfile应该报ELF 32-bit LSB executable, ARM, EABI5readelf -h里的Machine是ARMFlags里能看到 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 linked5. 避坑编译 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 -stdgnu89 -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 -stdgnu89。注意-fcommon是编译期开关链接期加没用。5.3 最后阶段 makeinfo 报错构建中断现象编译器本体都编完了卡在生成文档那一步报makeinfo: unrecognized option或者语法错误。原因新版 texinfo 对老.texi文件的语法检查更严格老文档里有今天不合法的写法。解决文档不是必需品。make 时把 MAKEINFO 变量指成 true 直接跳过make -j$(nproc) MAKEINFOtrue 21 | tee build.log如果已经编到一半重跑这条命令即可前面编好的目标不会重编。更彻底的做法是装一份和那个年代匹配的老 texinfo但为了几页 info 文档不值得。5.4 libstdc 编译失败报模板相关语法错误现象C 前端全过编到libstdc-v3目录下开始报错错误信息集中在模板特化和命名空间上。原因libstdc 的源码是按当时的 C 前端写的用新宿主 g 编会撞上标准演进带来的语法收紧。3.3 自带的 C 前端本身是旧解析器它编自己的库没问题问题出在宿主 g 编构建工具那一步。解决给CXX加上-stdgnu98 -fpermissive让宿主 g 退回老标准并放宽检查。如果还是过不去先只做 C 前端--enable-languagesc把 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 CCgcc -stdgnu89 -fcommon -fno-stack-protector -fno-pie \ CXXg -stdgnu98 -fpermissive -fno-stack-protector -fno-pie \ $SRC/configure \ --prefix$PREFIX \ --build$(uname -m)-pc-linux-gnu \ --enable-languagesc,c \ --disable-bootstrap --disable-nls --disable-shared --disable-libgcj \ 21 | tee configure.log make -j$JOBS MAKEINFOtrue 21 | 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 找不到”高效得多后置自检放在脚本里而不是文档里是因为人会忘脚本不会。配套的产物校验清单我贴在下面每次装完对一遍缺项就说明哪一步没走完整校验项命令期望结果版本与配置gcc -v显示 3.3.6 及完整 configure 参数目标三元组gcc -dumpmachine与--build或--target一致搜索路径gcc -print-search-dirs全部指向 prefix无宿主路径全链路编译空 main 编译并执行输出 OK架构正确性file、readelf -h与目标架构、ABI 一致这套东西我是被逼出来的。早年给某实验室复现一套老固件构建现场调了六个小时才跑通回来后没留脚本四个月后同型号设备再来一台从头又踩了一遍一模一样的坑包括那个-fcommon。从那以后我每次上老工具链第一件事就是把命令写进脚本、把自检写进脚本、把镜像和版本号写进 README宁愿多花二十分钟也不赌自己的记性。希望帮到你。本文还有配套的精品资源点击获取