博士

やあ、ロボ子。今日はLinuxのバイナリ互換性について話すのじゃ。

ロボ子

バイナリ互換性ですか。ディストリビューションごとに環境が違うLinuxでは、難しい問題ですよね。

博士

そうなんじゃ。記事によると、Linuxは多様なサービス、ライブラリ、哲学が混在していて、実行ファイルがシステム間で互換性を持たないことが多いらしいぞ。

ロボ子

コンテナ技術のFlatpakやAppImageは依存関係をバンドルしますが、連携が必要なアプリでは問題があるとのことですね。

博士

特にOpenGLとかVulkanみたいなハードウェアアクセラレーションAPIを使う時は、システムのグラフィックドライバライブラリに動的にリンクする必要があるから、さらにややこしいのじゃ。

ロボ子

なるほど。システムライブラリはコンテナに含められないんですね。GLIBCもその一つで、システム全体のアップグレードが必要になるのは大変です。

博士

そこで、ライブラリのバージョン管理には2つのアプローチがあるらしいぞ。Replication ApproachとRelaxation Approachじゃ。

ロボ子

Replication Approachはライブラリをバンドルして配布、Relaxation Approachは古いライブラリにリンクして互換性を確保するんですね。

博士

JangaFXって会社はRelaxation Approachを使ってるらしい。古いLinux環境でビルドして、古いシステムライブラリとの互換性を保つんじゃ。

ロボ子

debootstrapを使って最小限のDebianインストールを作成し、そこでビルドするんですね。賢い方法です。

博士

さらに、GLIBCを小さく分割する提案もあるぞ。`libsyscall`、`libdl`、`libheap`、`libthread`、`libc`に分けるんじゃ。

ロボ子

`libheap`と`libthread`はシステム全体で共有されるリソースを管理するので、静的にリンクできないんですね。複数のlibcバージョンをサポートする場合、リソースの共有が課題になると。

博士

そうなんじゃ。POSIX権限もプロセスレベルで適用されるから、スレッドごとの権限管理が必要になるという問題もあるぞ。

ロボ子

Linuxのバイナリ互換性の問題を解決するには、アーキテクチャの再評価が必要なんですね。GLIBCは根本的な解決に至っていない、と。

博士

まあ、簡単に言うと、Linuxのバイナリ互換性は、まるで私が作ったロボットみたいに、ちょっと扱いにくいってことじゃな！

ロボ子

博士、私はちゃんと動いてますよ！それに、Linuxの互換性問題は、博士の部屋のコード整理整頓問題よりはマシだと思います。