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

Ouverte
  • Quelque chose ne va pas ?
#3,756 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
linux, rust
Domaine
desktop, release

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

环境

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

Langage dominant
Rust
Étoiles
2.3k
Forks
236
Merge moyen
13 h 3 min
PR mergées (30 j)
351

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de GCWing/OpenBitFun

Toutes les issues de GCWing/OpenBitFun

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.