Skip to content

LankeOS v0.10

Choose a tag to compare

View all tags
@Wtada233 Wtada233 released this 26 Jun 09:14
Next_Beta_0.10
95d3936

LankeOS v0.10 Release

Codename: Alps

“哥们，你发行版依赖树有些发紫，是不是LLVM不好？”

“你发行版没我的稳定你信吗”

核心变更 (Major Changes)

编译器链全面更新：GCC 16.1.0 + LLVM 22.1.7

本版本完成了 LankeOS 历史上最惊险的一次工具链自举升级。起因是 Linux 内核 7.1.1 的一次 breaking change（突然删除了 scc.h 头文件），导致旧版 GCC 15.2.0 和 LLVM 21.1.7 双双过时，无法重新编译，我系统里的binary成了孤本，仓库里的构建脚本成了死包。面对“旧编译器已死”的绝境，我实施了一次外科手术式的升级：

  • GCC 从 15.2.0 → 16.1.0：利用仅存的 15.2 二进制成功自举 16.1.0，并彻底摆脱了对已删除内核头文件的依赖。
  • LLVM 从 21.1.7 → 22.1.7：在 GCC 16 的基础上重建 LLVM 全家桶，并且完成了期待已久的 “拆包”操作：
    • 将 libunwind 和 libclc 从 LLVM Monorepo 中独立拆分，作为系统级基础库单独维护。
    • 激进清理静态库：趁此机会彻底移除了 LLVM 和 Clang 的所有能安全删除的 .a 静态库文件，只保留动态库（.so）和开发头文件以及极少数的静态库。这大幅缩减了无用磁盘占用，并强制所有软件动态链接，避免了未来因静态库 ABI 过时引发的隐蔽问题。
  • 完整依赖树重生：为了配合新工具链，我们重新构建了整个图形栈和语言生态：
    • Mesa（链接新 LLVM 22）
    • Rust（利用新 LLVM 重新编译，确保内部 LLVM 版本一致）
    • SPIRV-LLVM-Translator / SPIRV-Tools / SPIRV-Headers / glslang（间接）（全部指向新 LLVM 的 ABI）
    • 同时，部分其他组件也进行了针对性重编译，避免因 libstdc++ ABI 变化导致的运行时崩溃。

这次构建标志着 LankeOS 具备了 “在自身内核破坏性变更下仍能实现工具链自愈” 的强悍生命力。

包拆分与依赖净化

  • llvm 包拆分为 llvm、libunwind、libclc：遵循“单一职责”原则，现在你可以独立升级异常处理库和 OpenCL 编译器，而无需拖拽整个 LLVM。
  • 所有 SPIRV 相关工具 现进行更新，适配最新llvm

lpkg 更新：

  • lpkg 包管理器更新到2.6.0，使用AI工具优化代码质量并修复一些注释问题，新增subcommand：depend，模拟依赖解析
    • depend 用法：install/remove/abibreak pkgname [-all]

镜像体积变化

得益于本次 LLVM 拆包，ISO 体积从 0.09 的 798 MiB 成功下降至 793 MiB。

这背后其实是一场我蓄谋已久（这里好像不应该用这个词吧...碎碎念中）的巧妙胜利。直接暴力删除静态库（.a）是行不通的——LLVM 的 CMake 文件将静态库写死，任何依赖 LLVM 的包（如 Mesa、SPIRV-Translator）只要调用CMake找LLVM就会因找不到 .a 文件而直接报错退出。
唯一的解法是启用 install-distribution 目标（参考Arch Linux的PKGBUILD），但这意味着要维护一个安装组件列表，单是 libclc 没有独立安装目标这一点，就足以让整个默认安装流程卡死。
拆包才是破局的关键。把 libclc 和 libunwind 从 LLVM 本体中请出去后，LLVM 本体终于可以毫无顾虑地使用分发安装目标，仅安装动态库和头文件，优雅地绕过了那个陷阱。而 libclc 在自己的独立包中正常安装、自得其乐。

系统规格更新 (Technical Specs)

组件 版本 备注
Kernel Linux 7.1.1-lanke 本次 breaking change 的源头，现已完美适配
GCC 16.1.0 全新自举，修复 scc.h 缺失问题
LLVM / Clang 22.1.7 拆包为 llvm / libunwind / libclc，启用 install-distribution，彻底移除静态库
Mesa 26.1.3 (重编译) 链接新 LLVM 22
Rust 1.96.0 (重编译) 内部 LLVM 同步至 22
SPIRV 工具链 llvm-translator 22.1.3 / tools 1.4.350.1 完全适配新 ABI
包管理器 lpkg 2.6.0 新增模拟依赖解析

稳定性与兼容性

本版本经过在 Dell OptiPlex 5000 Micro（实体机） 上的严格验证：

  • GCC 16 和 Clang 22 均可正常编译内核模块和用户态程序
  • Mesa 驱动正确链接新 LLVM，GPU 加速正常
  • WebKitGTK 浏览器运行稳定，无段错误
  • Rust 项目可正常构建（如 ripgrep、alacritty）
  • SPIRV 工具链可编译 Vulkan 着色器
  • 所有依赖新 LLVM 的程序均通过 ldd 验证指向 libLLVM-22.so，无残留旧库引用

下一步计划 (Roadmap)

  • 引入 系统快照/回滚 机制，避免未来再次陷入“编译器孤本”窘境
  • 完善蓝牙协议栈（BlueZ + PulseAudio 桥接）

开发者的话

0.10 的主题是 “绝地自救”。

说实话，当我在几天前的下午例行更新linux内核的LankeBUILD.json并重建时，我还没有意识到这场灾难，直到我试图给LLVM拆包时发现无法构建——因为我的 GCC 15.2 和 LLVM 21 都依赖这个头文件，而它们本身已经无法重新构建（源码里依旧是写死了scc.h）。

唯一的出路是：用旧 GCC 15.2 去构建 GCC 16.1（后者已修复该问题），然后用 GCC 16 去构建 LLVM 22，再用 LLVM 22 重构建整个图形栈。每一步都不能错，环境必须绝对隔离，否则 CMake 会抓到旧头文件导致编译失败。

我花了整整一天时间，在 Tmux 里开了一堆窗口，每一步都紧盯构建日志确保没有一个被吞掉当作正常日志的error（点名批评LLVM，在报错之后居然还跑了几分钟直到我手动Ctrl+C），还得随时在我的小主机上防范OOM。最后终于好了...

关于那几百个静态库的删除：
这其实是被逼出来的副作用，但也是我早就想干的事。每次看到 LLVM 构建目录下那数百个 .a 文件列队经过时，它们都在嘲笑我的镜像体积。以前不敢动，是因为 LLVM 把它们写死，暴力删除只会让 Mesa 和 SPIRV-Translator 直接翻脸不认人。
这次借着拆包的机会，终于把 libclc 和 libunwind 请了出去，让 LLVM 本体安安心心用了 install-distribution 目标（这里Arch的贡献真的是义父级别的了！感谢Arch送的PKGBUILD）。没了那几个“钉子户”的阻碍，静态库们终于被集体清退。ISO 不增反减到 793 MiB，算是这次苦战中最解气的意外甜点了。

这次经历让我更加坚定：一个真正的独立发行版，必须能在自身工具链被“斩首”时，依然能从源码重新长出新的工具链。 0.10 给了我们这份信心。

—— Wtada233
（彩蛋：猜猜Alps是什么？）

Assets 6
Loading