RevyOS上的工程软件生态观测 (6): 构建之旅：从入门到放弃 (下)：我来 port？真的假的？

测试矩阵
1

大家好，我是 PLCT 丁丑小队的一名实习生。这是我们工程软件测试系列帖的第六篇，接续上篇。

在前几期，我们分享了从“开箱即用”到“需要一番折腾才能搞定”的各种软件。然而，探索的道路上并非总是一帆风顺。本期，我们将扮演一次“法医”，对那些我们付出了巨大努力但最终仍以失败告终的案例进行一次“尸检”。

记录失败与记录成功同样重要。这些构建失败的案例揭示了将存量开源软件生态迁移到 RISC-V 等新兴平台时所面临的深层次挑战。不过希望不是因为我们测试时的 skill issue。

案例分析一：时代眼泪 —— 因代码过于古老而失败

许多优秀的开源软件诞生于十多年前，它们曾经稳定可靠，但其所依赖的语言版本、库和构建工具已被时代淘汰。

  • 软件案例: VisTrails, PythonCAD, FElt, FELyX

  • 失败原因:

    1. Python 2 依赖: VisTrails 和 PythonCAD 均依赖于早已停止维护的 Python 2.x 以及 PyQT4。当我们尝试在 Python 3 环境下运行 VisTrails 时，解释器立即因为无法识别 Python 2 的 0L (长整型) 语法而崩溃。由于 RevyOS 源中已无 Python 2 环境，这类软件已无法直接运行。
      File "/path/to/vistrails/core/api.py", line 155
  vistrail.add_action(action, 0L)
                              ^
SyntaxError: invalid decimal literal
    2. 过时的 C++/构建工具: FElt (2009) 和 FELyX 的代码充满了与现代 C++ 标准（如 C++11 及以后）不兼容的写法。例如，FELyX 的代码中存在需要手动将 current 修改为 this->current 才能通过编译器类型推导的语法问题。同时，FElt 的构建脚本与新版的 bison/flex 工具完全无法协同工作。

  • 结论: 对于这类软件，简单的 patch 已无济于事，需要进行大规模的代码现代化重构，这几乎等同于一次彻底的重写。

  • 详细报告:

案例分析二：依赖深渊 —— 复杂的依赖管理问题

这类软件本身可能没有太大问题，但它们的依赖关系复杂、版本要求苛刻，或者干脆就是年久失修。

  • 软件案例: enGrid, deal.II

  • 失败原因:

    1. 依赖库版本不匹配与资源耗尽: deal.II 是一个庞大的 C++ 有限元库。首先，RevyOS 源中提供的 libdealii-dev 包本身存在问题——它依赖 Boost 1.83，但自身却是用 Boost 1.74 编译的，导致任何尝试链接它的程序都会因版本断言失败而无法编译。其次，当我们尝试从源码编译 deal.II 时，在 Lichee Pi 4A (16G RAM) 上编译了数小时后，最终因内存耗尽 (OOM) 而被系统终结。这暴露了在资源受限的开发板上本地编译大型项目的物理瓶颈。
    2. 失效的依赖源与过时的库: enGrid 的构建脚本写死了一个从 http://engits.eu 下载特定版本 netgen-4.9.13 的逻辑，而这个 URL 早已失效。更棘手的是，它强制依赖 Qt4 和 VTK 5，这两个库在现代 Debian/RevyOS 中已被 Qt5/6 和 VTK9 全面取代，API 亦不兼容。

  • 结论: 依赖问题是软件移植中最常见也最头疼的一类。无论是上游打包错误、硬件资源限制，还是软件本身依赖于早已被废弃的组件，都可能导致构建失败。

  • 详细报告:

案例分析三：架构鸿沟 —— 真正的平台不兼容

这是最深层次的问题。软件代码中包含了对特定硬件架构或图形 API 的隐式假设，导致在新平台上无法编译。

  • 软件案例: Paraview, VisIt
  • 失败原因: 遗留 OpenGL API 依赖。这两款强大的可视化软件都依赖于 VTK。在编译 VTK 相关模块时，我们遇到了相同的致命错误：
    error: ‘GL_BACK_LEFT’ was not declared in this scope
error: ‘GL_BACK_RIGHT’ was not declared in this scope
    GL_BACK_LEFT 等宏是用于立体渲染的，属于传统的、完整的桌面级 OpenGL (Full Desktop OpenGL Profile) 规范。然而，许多现代嵌入式设备（包括我们测试用的开发板）的 GPU 驱动仅支持 OpenGL ES (GLES) 或现代的 OpenGL 核心配置文件 (Core Profile)。在这些现代规范中，许多旧的、固定管线的 API（包括这些宏）已被废弃和移除。

Paraview 编译失败
Paraview 编译失败1920×1200 390 KB

  • 结论: 解决这个问题需要对 VTK 和 Paraview 的渲染后端进行真正的移植 (porting) 工作，使其兼容 GLES 或 Core Profile，这远远超出了常规构建和 patch 的范畴。
  • 详细报告:

总结

本期我们展示的失败案例，揭示了软件生态建设的复杂性。从语言迭代、依赖管理到硬件架构差异，每一个环节都可能成为阻碍。但正是这些失败，为我们指明了未来工作的方向：哪些软件需要社区投入精力去现代化，哪些核心库（如 VTK）亟待在 RISC-V 平台上完成底层移植。

下一期，也是本系列的最后一期，我们将轻松一下，聊一聊那些在互联网上几乎消失殆尽的“失传的软件”。

欢迎各位复现/吐槽丁丑小队的所有测试结果。
如果有对我们的测试方法/结果有任何建议/问题,欢迎直接在 GitHub 开 issue,或者在论坛 @ 我们、回帖询问。

7 个赞
2

:memo::memo::memo::memo::memo: 出错了：正文 似乎不清楚，这是一个完整的句子？