現在のバージョンのWindowsで実行されている実行可能ファイルをビルドする場合、その実行可能ファイルは長年にわたって最新バージョンのWindowsで実行できます。マイクロソフトはこれを確実にするために非常に懸命に取り組んでいます。
Linuxでは、使用しているソフトウェアのソースコードが必要であるため、ソース互換性が維持される限り、バイナリ互換性を破るのは問題ありません。これにより、ディストリビューションは以前のライブラリバージョンを段階的に中断し、かつて機能していた機能を定期的に中断します。
ゲームはバイナリ形式でのみ配布されることが多いため、これはLinuxをゲームプラットフォームとして使用している人にとっては問題になります。 Linuxポートがダウンしているのは残念ですが、誰もがポートを更新するのを期待するよりも一般的に問題を解決しようとする方が生産的であると思います。
すべての古いバージョンを必ずしも維持するわけではありませんが、少なくともバージョンnで動作するバイナリがバージョンn + 1でも動作できるように、以前のsonameを維持しながらバイナリ互換性を維持しようとするディストリビューションはありますか？
私が見つけることができる最も近いのは、Steamを介して配布されるプログラムでのみ機能するバイナリ互換性レイヤであるValveの「Steam Runtime」です。
ベストアンサー1
デフォルトでは、これは次のように要約されます。バイナリ互換性を維持し、新機能を導入することはできません。なぜなら、これらはほとんどの方法で互いに直接反対するからです。新しい主な機能を導入したら〜しなければならないABIを変更します（通常はAPIが変更された直後）。 Glibcのようにバージョン管理されたシンボルを使用できるようになりましたが、ライブラリのサイズが大きくなり（バイナリをメモリにロードするとパフォーマンスが低下する可能性があります）、開発者は一般的にライブラリ（レガシーコードには誰も修正することに興味がないバグ含まれています。
展開の面でこの問題を解決するには、2 つの一般的な方法があります。
バージョンを変更しないでください。これは、RedHat、SUSE、およびその他の一部（Debian、Slackware、Ubunty LTS、およびそれらのレプリカ）などのエンタープライズレベルのディストリビューションで一般的です。
さまざまなバージョンのライブラリを同時にインストールできます。
アプリケーションディストリビュータは、Windowsと同じ方法で進みます。配布パッケージに必要なすべてを入力します。はい、これがWindowsで動作する方法です。これは、一般的なWindowsシステムのディスク容量要件が同じ機能を備えたLinuxよりも多くの場合、何倍も高い理由の1つです。アプリケーションはお互いにほとんど共有しておらず、特定のシステムではどこにでも独自のコピーがあります。各GTK / Qtアプリケーションには独自のGTK / Qtスタックが含まれていると考えることができます。いくつかの利点があるかもしれませんが、欠点もたくさんあります。たとえば、TechnicolorTMはセキュリティの観点から見て悪夢です。バイナリが静的にリンクされている場合は、フルHDも可能です。