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

Aberta
  • Algo errado?
#3,756 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
linux, rust
Domínio
desktop, release

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

环境

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

Linguagem predominante
Rust
Estrelas
2.3k
Forks
236
Merge médio
13h 3min
PRs com merge (30d)
351

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de GCWing/OpenBitFun

Todas as issues de GCWing/OpenBitFun

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.