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

Aperta
  • Qualcosa non va?
#3,756 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
linux, rust
Ambito
desktop, release

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

环境

  • 发行版：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 输出。

Lingua principale
Rust
Stelle
2.3k
Fork
236
Merge medio
13h 3m
PR unite (30g)
351

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di GCWing/OpenBitFun

Tutte le issue di GCWing/OpenBitFun

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.