問題があるソフトウェア
2025/4/5時点のbroken-softwareの翻訳
このページでは、Apple Silicon 機器では正しく動作しないことが知られているソフトウェアをリストアップしています。 これを公開することで、コミュニティのメンバーが影響を受けるパッケージの修正を上流に提供する動機となり、AArch64ソフトウェアの エコシステムがより良くなることを期待しています。
${PACKAGE} が AArch64 に対応しているのに、なぜ動かないのでしょうか?¶
これはほとんどの場合、16K ページへの対応が正しくないか、不完全であることが原因です。 パッケージが4Kのページサイズを想定して作られていたり、大きなページと互換性がない場合があります。 デスクトップ Linux のソフトウェアではこれは深刻な問題ではありませんでした。 x86/amd64 では 4K ページしか対応しておらず、PowerPC では 4K または 64K ページしか対応していないからです。 AArch64 は、AArch64 機器が 4K、 16K _ または_ 64K ページを使うことができるという点で独自です。
なぜ4Kページを使わないのですか？¶
これらの機器は 4K カーネルをブートできますが、そうするためには非常に面倒なパッチが必要です。 IOMMU は 16K-aligned ページ しか対応していないからです。 これは性能上の重大な問題を引き起こすだけでなく、AArch64に不完全な対応しているユーザースペースの ソフトウェアという実際の問題にも対処していません。 XNU(macOS)はユーザー空間で独立したページサイズに対応することでこの問題を回避していますが、 Linuxにはそのようなメカニズムはありませんし、おそらく今後もないでしょう。
なぜ固定バージョンの ${PACKAGE} を自分でホストしないのですか?¶
デスクトップクラスの AArch64 マシンは今後数年間でより一般的になることが予想されます。上流優先のポリシーを持つことで、 これらの修正がディストリビューションのリポジトリを通じてすべての人に伝搬され、AArch64 のエコシステムをすべての人の ために改善することが確認できます！ 修正済みパッケージ をご覧ください。この結果としてすべての 人のために修正されたソフトウェアのリストがあります。Emacsを私たちだけのものにしたくないでしょう?
なぜ『動作しない』ことが『即座のsegmentation fault』を意味するのですか？¶
ELFの実行ファイルやライブラリが16Kページにアライメントされていないセクションを持つ場合、ローダーはバイナリをメモリに マップすることができず、この失敗をsignalで知らせ、segmentation faultを発生させます。
このことは readelf -l /path/to/binary を使って確認することができます。タイプ LOAD のすべてのプログラム
ヘッダーセクションは、 Apple Siliconのような16Kのマシンで正常に読み込むためにはALIGN 値が少なくとも 0x4000 で
ある必要があります。ここで説明されているライブラリは 4K ページ (0x1000) にしかアラインされていないので、ロードできません。
$ readelf -l lib64/ld-android.so
Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000001f8 0x00000000000001f8 R 0x8
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000874 0x0000000000000874 R 0x1000
LOAD 0x0000000000001000 0x0000000000001000 0x0000000000001000
0x0000000000000004 0x0000000000000004 R E 0x1000
LOAD 0x0000000000002000 0x0000000000002000 0x0000000000002000
0x00000000000000a0 0x00000000000000a0 RW 0x1000
DYNAMIC 0x0000000000002000 0x0000000000002000 0x0000000000002000
0x00000000000000a0 0x00000000000000a0 RW 0x8
GNU_RELRO 0x0000000000002000 0x0000000000002000 0x0000000000002000
0x00000000000000a0 0x0000000000001000 R 0x1
GNU_EH_FRAME 0x000000000000082c 0x000000000000082c 0x000000000000082c
0x0000000000000014 0x0000000000000014 R 0x4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 0x0
NOTE 0x0000000000000238 0x0000000000000238 0x0000000000000238
0x0000000000000020 0x0000000000000020 R 0x4
Section to Segment mapping:
Segment Sections...
00
01 .note.gnu.build-id .dynsym .gnu.hash .dynstr .eh_frame_hdr .eh_frame
02 .text
03 .dynamic
04 .dynamic
05 .dynamic
06 .eh_frame_hdr
07
08 .note.gnu.build-id
AArch64コンパイラのデフォルトは、すべてのAArch64機器との互換性のために、64KにアラインされたセクションでELFファイルを生成するが、
ツールバグ(例えば古いバージョンの patchelf によって操作されたバイナリ) や、カスタマイズされたコンパイラフラグ (例えば
古いバージョンの Chrome (および Electron) や最新の Android プログラムを含む多くの Google プログラム) によって、
セクションが4Kにしかアラインメントされていないバイナリが生成されることがあります。
入手可能なワークアラウンドはありますか？¶
Fedora Linux Asahi Remix の muvm パッケージは標準で 4K カーネルを仮想化するよう設定されています
(FEX を x86_64 binfmt ハンドラーとしているならば x86_64 プログラムも動作するでしょう)。
muvm 内でソフトウェアを実行してみれば成功の度合いが変わるでしょう。
問題があるパッケージ¶
| パッケージ | 上流への報告 | 注釈 |
|---|---|---|
| hardened_malloc | https://github.com/GrapheneOS/hardened_malloc/issues/183 | 16kページ対応する前にhardened_mallocに多くの変更が必要。MTEが必要でkこの時点では高優先度ではない |
| jemalloc | https://github.com/jemalloc/jemalloc/issues/467 | 上流は修正する気がない、4kページサイズシステムでコンパイルするならビルドオプションが必要。 ArchLinuxARM](https://github.com/archlinuxarm/PKGBUILDs/pull/1914)で対応 |
| jemalloc | https://github.com/archlinuxarm/PKGBUILDs/pull/1914 | ページサイズ≧システムに対してコンパイルしたときだけ動作 |
| MEGAsync | https://github.com/meganz/MEGAsync/pull/801 | |
| notion-app(-enhancer) | https://github.com/notion-enhancer/notion-repackaged/issues/107 | electron + 壊れたビルドフラグ |
| Wine | https://bugs.winehq.org/show_bug.cgi?id=52715 |
* x86-64 ソフトウェアの実行は FEX を実行している 4k ページサイズの microVM 経由で対応します。
修正済みパッケージ¶
バグ¶
サードパーティソフトウェアの問題（ページサイズやアーキテクチャ上の問題を除く）で、Asahiのコアチームメンバーによって報告または追跡されているもの：