从零编译 Chromium 浏览器（Manjaro Linux）
这篇没什么高深的东西，就是踩坑记录。Chromium 的官方文档只照顾 Ubuntu 用户，Manjaro 上跑一遍全是暗坑，记下来下次少走弯路
环境：Manjaro Linux（Arch 系）
版本：Chrome 151.0.7900.0，V8 15.1.143。
今夕是何年：2026 年 06 月 19 日 星期五 09:48:07 CST (嘿，端午节)
编译这个是为了我的一个项目，剪裁浏览器，把一些我们在自动化过程中不用的功能砍掉，比如历史浏览记录，下载管理，书签之类的东西，还有就是可以更深入的理解浏览器指纹是怎么产生的，应该怎么去追他们的使用路径，了解浏览器核心
拉源码：代理并发是第一个坎
Chromium 用 depot_tools 管理源码，fetch 一把梭。加 --nohooks --no-history 跳过 hook 和全量历史，省流量省时间：
mkdir -p ~/NewCode/WebPage/Chromium/ChromiumSrc && cd $_
fetch --nohooks --no-history chromium
跑起来直接炸——gclient sync 默认并发拉几十个子仓库，全走代理瞬间堵死，大量 fetch 失败。
解决办法很简单，我走了一个很操蛋的方法
- 使用 Git 进行克隆浏览器主体项目
- 在 src 目录内再使用
gclient进行同步几百个子目录模块
git clone --depth 1 --progress https://chromium.googlesource.com/chromium/src.git src
cd src # 我是这样做了，实际上在src外也可以的
gclient sync --nohooks --no-history
硬克隆有点难绷了，但是我也不知道为啥，AOSP 和 Lineage OS 都能找到镜像源但是为啥 Chromium 没国内源
装依赖：Arch 可能还是被用的少了
Chromium 自带的 build/install-build-deps.sh 只支持 Ubuntu/Debian，Manjaro 不在支持列表里。手动用 pacman 装：
sudo pacman -S --needed base-devel python gperf bison flex pkgconf nss alsa-lib \
gtk3 cups dbus libnotify gnome-keyring libxss libxtst libxcomposite libxrandr \
libxdamage pango atk at-spi2-core krb5 mesa libva
都是编译和运行时需要的库，缺一个后面都可能报诡异的链接错误。Google 的文档不会告诉你这些——它们假设你在 Ubuntu 上，所有东西 apt 一把过。
跑 Hooks：等就完了
gclient runhooks
这一步下载 clang 工具链、sysroot、vpython3 等，全从 Google 服务器拉。其中 vpython3 install 一个 hook 就跑了 100 多秒。没什么技巧，挂代理等着就行。
踩坑：LASTCHANGE 文件缺失
如果跳过 hooks 直接跑 gn gen，会报错找不到 build/util/LASTCHANGE.committime。Chromium 的构建系统用这个文件标记版本时间戳，手动生成：
python3 build/util/lastchange.py -o build/util/LASTCHANGE
python3 build/util/lastchange.py --revision-id-only --header build/util/LASTCHANGE.committime
这是我想偷懒不跑runhooks但是发现还是得跑
生成构建配置
gn gen out/Default --args='is_debug=false is_component_build=true'
两个参数：
is_debug=false：Release 模式，编译产物小很多is_component_build=true：组件化构建，改一个文件不用全量重编，开发阶段必开
后续剪裁的时候 gn args 会越来越复杂，砍功能就是在这里做文章。但第一次编译先跑通，先让可见的成功激励一下自己
编译
autoninja -C out/Default chrome
提示 offline mode 是正常的——RBE 远程编译是 Google 内部服务，外部开发者只能本地来。全量编译取决于硬件，我这跑了好几个小时。
踩坑：子仓库未拉取完整
编译时报某个 .json 文件 missing，查了一圈发现是 gclient sync 时部分子仓库只创建了 .git 目录但没有 checkout 出文件。去 src/DEPS 找到对应的 commit hash，手动拉：
cd third_party/search_engines_data/resources
git fetch --depth 1 origin <commit-hash>
git checkout FETCH_HEAD
或者直接再跑一次 gclient sync -j 4，让它自动补全。
跑起来
编译产物在 out/Default/chrome：
./out/Default/chrome
版本信息：
Chrome 151.0.7900.0 (开发者内部版本) (64 位)
V8 15.1.143
用户代理 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36
修订版本全 0 是因为 --no-history 浅克隆，不影响功能。
顺手解决：zsh 在超大仓库下的卡顿
Chromium 几十万个文件，oh-my-zsh 的 git 插件每次 prompt 都跑 git status，按一次回车等一两秒。在仓库内关掉：
git config --local oh-my-zsh.hide-dirty 1
git config --local oh-my-zsh.hide-status 1
prompt 恢复毫秒级响应，其他仓库不受影响。需要看分支时手动 git branch。
总结
整个过程最大的障碍不是代码，是网络——从国内通过代理拉 Google 服务器的源码和工具链，不稳定是常态。核心经验就四条：
- 降并发：
gclient sync -j 4，别让代理扛不住
- 反复跑：
gclient sync 可以重试，已成功的不会重复
- 手动补缺：missing 文件查 DEPS 找 commit hash，手动 fetch
- 先跑通再剪：第一次编译别折腾 gn args，跑通再说
相比 AOSP/LineageOS 的编译体验，Chromium 省心不少——gn gen 过了基本一路到底，不需要一直盯着修错。
操蛋的是编译期间随手更新了 mesa，然后 Obsidian 打不开了，报 libLLVM.so.22.1 找不到。跟 Chromium 编译本身没关系，但提醒我——搞这种大工程的时候别同时动系统库，出了问题排查方向都是乱的。
发表于 2026-6-19 16:10
分享到朋友圈
