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

Offen
  • Stimmt etwas nicht?
#3,756 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
linux, rust
Bereich
desktop, release

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

环境

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

Vorherrschende Sprache
Rust
Sterne
2.3k
Forks
236
Ø Merge
13 Std. 3 Min.
Gemergte PRs (30 T.)
351

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus GCWing/OpenBitFun

Alle Issues in GCWing/OpenBitFun

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.