[Bug] Linux RPM 1.0.9 无法启动：二进制要求 libbz2.so.1.0，Fedora/RHEL 只提供 libbz2.so.1（exit 127）

Abierto
  • ¿Algo no está bien?
#3,756 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
linux, rust
Área
desktop, release

Línea de trabajo

Start by inspecting the Linux x86_64 RPM build and packaging configuration, then compare the binary’s shared library requirements with the RPM dependencies on Fedora. Confirm the fix by checking that the built binary starts and that the RPM declares its runtime dependencies; the issue is resolved when Fedora/RHEL users can launch the updated application without a missing bzip2 library.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

环境

  • 发行版：Fedora 44（KDE Plasma，Wayland，x86_64）
  • bzip2-libs：1.0.8-23.fc44（提供 libbz2.so.1 → libbz2.so.1.0.8，不提供 libbz2.so.1.0）
  • 安装形态：官方 RPM（包名 open-bit-fun），由应用内建更新器（tauri_plugin_updater，pkexec 安装）从 1.0.8 升到 1.0.9

现象

1.0.8 一切正常。内建更新器下载并用 pkexec 安装 1.0.9 后自动重启，此后双击图标完全没有反应：没有窗口、没有对话框、没有错误提示。

应用日志确认更新器确实安装并触发了重启（~/.config/openbitfun/logs/20261106T034017/app.log）：

[2026-11-06T03:40:55.325][DEBUG][tauri_plugin_updater::updater] installed "/tmp/tauri_rpm_updateBxymdd/package.rpm" with pkexec
[2026-11-06T03:40:55.348][INFO][openbitfun_desktop_lib] Desktop process graceful shutdown completed
[2026-11-06T03:40:55.348][INFO][openbitfun_desktop_lib::api::system_api] Desktop restart authorized after graceful shutdown
[2026-11-06T03:40:55.348][DEBUG][tauri::app] restart triggered from a separate thread

之后每一次启动，systemd user journal 都是同一条错误：

/usr/bin/openbitfun-desktop: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory
[email protected]: Main process exited, code=exited, status=127/n-a

根因

1.0.9 的 openbitfun-desktop 的 DT_NEEDED 里，bzip2 的 soname 是 Debian/Ubuntu 风格的 libbz2.so.1.0：

$ objdump -p /usr/bin/openbitfun-desktop | grep NEEDED
  NEEDED               libbz2.so.1.0
  ...

而 Fedora 的 bzip2-libs 长期把它改名为 libbz2.so.1：

$ ls -l /usr/lib64/libbz2*
/usr/lib64/libbz2.so   -> libbz2.so.1
/usr/lib64/libbz2.so.1 -> libbz2.so.1.0.8     # 没有 libbz2.so.1.0 这个名字

同一个库、ABI 完全一致，只是 soname 名字不同 → 动态加载器直接失败，进程 exit 127。

对照：1.0.8 的二进制 NEEDED 是 libbz2.so.1，在同一台机器上完全正常。看起来 1.0.9 的 Linux 构建换用了另一个构建环境（其 libbz2 来自未做 Fedora 改名补丁的发行版，或用上游 bzip2 1.0.8 默认 SONAME 编译）。

为什么 dnf 没拦住

1.0.9 的 rpm 的 Requires 只有两条：

$ rpm -qp --requires OpenBitFun_1.0.9_linux-x86_64-rpm.rpm
libwebkit2gtk-4.1.so.0()(64bit)
libgtk-3.so.0()(64bit)

没有 libbz2.so.1.0()(64bit)，所以 rpm/dnf 认为依赖满足，安装直接成功，问题只在运行时暴露。

影响面

  • 所有 Fedora / RHEL / CentOS Stream 用户升级到 1.0.9 后应用永久无法启动
  • app.auto_update 默认开启，更新器装完立即自动重启，用户会处于「正在用的应用突然消失、再也打不开」的状态
  • 1.0.9 的 release notes 没有任何相关提示

临时绕过（已在 Fedora 44 验证）

$ mkdir -p ~/.local/lib/openbitfun-compat
$ ln -sfn /usr/lib64/libbz2.so.1 ~/.local/lib/openbitfun-compat/libbz2.so.1.0

$ LD_LIBRARY_PATH=~/.local/lib/openbitfun-compat /usr/bin/openbitfun-desktop --version
# → 正常加载并退出

$ /usr/bin/openbitfun-desktop --version
# → error while loading shared libraries: libbz2.so.1.0 ... （退出码 127）

ldd 对比也证实 1.0.9 缺失的只有这一个库：

$ ldd /usr/bin/openbitfun-desktop | grep 'not found'
	libbz2.so.1.0 => not found

$ LD_LIBRARY_PATH=~/.local/lib/openbitfun-compat ldd /usr/bin/openbitfun-desktop | grep 'not found'
# （无输出）

建议修复

  1. 根治：1.0.9+ 的 Linux x86_64 构建把 DT_NEEDED 改成 libbz2.so.1，或在构建时静态链接 bzip2，并确认构建基线里不含 Ubuntu 风格的 soname（Debian/Ubuntu 通常也提供 libbz2.so.1 兼容链接，反过来不会出问题）。
  2. 兜底：rpm 里显式声明 Requires: libbz2.so.1()(64bit)（或恢复自动依赖生成），让 dnf 能在安装阶段拦住。
  3. 更新器自保：安装新版后做一次冒烟检查（openbitfun-desktop --version，或扫描 ldd 的 not found），失败就回滚到上一个 rpm 并在 UI 明确提示——不要留下「装完就再也起不来」的状态。这一点对 Linux 侧特别重要，因为桌面图标启动失败时用户拿不到任何可见错误。

补充

1.0.9 的更新说明（多设备工作台、长会话性能、Generative UI 等）很期待，但目前 Fedora 用户进不了应用。如果需要更详细的取证，我可以补充完整的 journalctl --user 片段、objdump -p 全量 NEEDED 列表和 rpm 的 --requires/--provides 输出。

Lenguaje dominante
Rust
Estrellas
2.3k
Forks
236
Merge medio
13 h 3 min
PR fusionados (30 d)
351

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de GCWing/OpenBitFun

Todos los issues de GCWing/OpenBitFun

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.