24.04も22.04用でOk
Windowsでは、例えば、Windows7用にビルドした実行ファイルがWindows11で動作するのは当たり前の話になる。
何故なら、Windowsでは、大昔から実行ファイルの互換性を重視してきているので、新しいバージョンを開発し、それ用に新しいAPIを提供する場合にも、より古いバージョン用にビルドされた実行ファイルも、動作できる様に、古いAPIも残してきているからだ。
つまり、Windowsでは、より古いバージョン用にビルドしておけば、より新しいバージョンのWindowsでも、その実行ファイルは動作するので、開発者的には配布パッケージを作るのが楽な訳だ。
同じ様な話は、macOSにも言えるのだが、Linuxの場合、少なくとも大昔には、事情が異なった。
何故なら、古いバージョンのLinux用に実行ファイルをビルドすると、普通は、そのバージョンのLinuxに搭載されている各種ライブラリを動的リンクする様にビルドされるのだが、より新しいバージョンのLinuxでは、それらのライブラリが搭載されていない！ というのが、当たり前だったりしたからだ。
つまり、Linuxでは、前のバージョン用にビルドされた実行ファイルが、新しいバージョンでは動作しない！ というのが当たり前だったのだが、これは、LinuxがUNIXを真似て作られたOSだった、という事と無縁ではない筈だ。
何故なら、UNIXというOSは、様々なCPUが群雄割拠していた時代に開発されたOSなので、アプリケーションソフトは、普通は、ソースファイルとビルド用のスクリプトなんかで提供され、それぞれのCPU用の実行ファイルは、ユーザー環境でビルドする様にされていたからだ。
つまり、アプリケーションソフト開発者は、ユーザー環境を構成しているCPU環境を持ち合わせていない事も多かったので、アプリケーションソフトをインストールさせる場合、ユーザー環境で、ビルドする格好にしたので、その結果として、実行ファイルの互換性？ 何それ、美味しいの？ みたいな感じだった訳だ。
なので、そんなUNIXを真似て作られたLinuxでも、アプリケーションソフトの位置付けとしては、そんな感じで、ソフトはソースコードで配布され、自らの環境で利用したい場合には、自らの環境用にビルドしてから使用しろ！ みたいな感じだった訳だ。
これに対して、UNIXマシン以外のPCだとかMacでは、バイナリ互換が重視されたのだが、これには主に二つの理由があった筈だ。
その一つ目としては、アプリケーションソフトをインストールするのに、そのマシンで、ビルドしなければならない、なんてのは、少なくとも大昔のPC/Mac環境では、処理が重すぎた、という事があった筈だ。
例えば、作者的には、CP/M80時代には、コンパイラとして、どこからか入手できたBDS-CだとかTurbo Pascalを使えたのだが、当時のPCが利用できるメモリは最大でも64kBだったし、外部記憶はフロッピーディスクだった訳だ。
なので、比較的大きなプログラムをビルドするのは大変だったのだが、それ以前の話として、CP/M80にはC/Pascalコンパイラは内蔵されていなかった。
そんな8Bitコンピュータ時代が終わった16Bitコンピュータ時代になっても、CコンパイラやPascalコンパイラなんかは無料提供されていなかったので、アプリケーションソフトをビルドしないとインストールできない場合、ユーザー的には、まず、ビルドに必要になるコンパイラを購入しなければならなかった訳だ。
また、黎明期のパソコンユーザーは、プログラムのビルドくらいは出来る人が殆どだった筈なのだが、例えば、バカ売れたしたPC-9801用の一太郎を購入した人の何割がプログラムのビルドが出来たのか、と、考えると、その時期には、もう、1割もいなかったかもしれない。
と、いう事で、商業ベースのソフトが販売される様になったMac / MS-DOS / Windowsでは、アプリケーションソフトのビルドは大変な作業だった、という事もあり、ソフトは、ソースコードではなく、実行ファイルとして配布されるのが常識になっていった訳だ。
ソフトが実行ファイル形式で配布される様になっていったもう一つの理由としては、PC9801用のゲームソフトなんかが販売される様になると、そのソフトはFDDメディアに書き込まれて販売され、かつ、そのメディアにはコピープロテクトがかかったりする様になった、という事と無縁ではない筈だ。
何故なら、当時は著作権は、ほぼ、無視されていたので、ソフトウェアは、コピープロテクトしておかないと、購入したユーザーがコピーして不特定多数向けに配布してしまったで、そのソフトは発売開始時に数パッケージ売れても、その後は全く売れなくなってしまった訳だ。
このため、物理的に販売したフロッピーメディアがFDDに挿入されていない限り、そのソフトは正常動作しない！ みたいなコピープロテクトを入れる事で、ゲームソフトメーカーは経営破綻から逃れる様にしていた訳だ。
似た様な話として、商業ベースのソフトが多数存在したMac / MS-DOS / Windowsでは、ユーザー環境でビルドできる様なソフトを提供してしまうと、いくら、自らのサーバーにアクセスして正規購入者である事を確認する様な機能を入れておいても、その機能は簡単に削除されてしまう訳だ。
そうなってしまうと、ソフト開発会社は経営破綻してしまうので、そういった不正利用防止用の機能が簡単に削除されてしまわない様に、ソフト開発会社的には、プログラムは簡単にリバースエンジニアリングできない様に、実行ファイルの形態で配布する様にした訳だ。
と、いう事で、商業ベースの企業がソフトを提供するMac / MS-DOS / Windows環境では、ソフトをユーザー環境でビルド可能なソースコードとして提供する様な形態は流行らなかった。
もっとも、そんなMac / MS-DOS / Windows環境用にも、所謂、オープンソース系のソフトは、ソースコードが提供されたりしているのだが、そんなオープンソース系のソフトでも、Mac / Windows環境用の配布パッケージは、基本的には、実行ファイル形式になっている筈だ。
これは、前述の様に、Mac / Windows環境では、プログラムをビルドするのは大変である一方で、これらの環境では、実行ファイルのバイナリ互換が確保されているので、提供者側がビルドしたバイナリを配布しても、普通は、全てのユーザー環境で動作するからだ。
にも関わらず、Linuxでは、バージョン毎にバイナリ互換がなく、アプリケーションソフトはユーザー環境でビルドしないと動作しない！ なんてのは、時代錯誤もいい所！ かもしれないのだが、今時のLinuxには、ソースコードが提供されずに配布されているソフトも増えてきた訳だ。
何故なら、Linuxでも、使用されるCPUはWindowsと変わらないし、その他のハードウェア的にも、Windows PCと変わらない、というか、普通は、Linux用のPCなんて存在していないので、Linuxでは、Windows PC用のハードウェアが使われているからだ。
にも関わらず、Linux自体は、大昔のCPUが群雄割拠していた時代のUNIXの作法に従って、アプリケーションソフトはユーザー環境でビルドするのが正しいコンピュータの使い方だ！ なんて事を言っていると、コンピュータユーザーを本当のUNIXマシンであるところのMacだとか、一般ウケが良いWindowsマシンなんかに奪われてしまう！
と、いう危機感を持ち始めたのか、最近のLinuxでは、従来バージョン環境下でビルドしたバイナリが新しいバージョン環境でも動作する事が増えた様な気がしていたのだが、Mirror-DTC Ver1.4.4については、Ubuntu22.04LTSでビルドしたバイナリが、Ubuntu24.04LTSでも動作する事が確認できた。
更に言えば、Ubuntu20.04LTS用にビルドしたバイナリは、Ubuntu22.04LTSでも動作している。
なので、確認はしていないのだが、Ubuntu20.04LTS用の実行ファイルはUbuntu24.04LTSでも動作するかもしれないのだが、とりあえず、今のところは、Ubuntu20.04LTS用のバイナリはUbuntu20.04LTS環境、Ubuntu22.04LTS用のバイナリはUbuntu24.04LTS環境でビルドして配布パッケージ化している。
と、いう事で、Linuxも、CPUが群雄割拠な時代はとうの昔に終わっているので、アプリケーションソフトのバイナリ互換を気にし始めているのかもしれないのだが、数日前まで文句を書いていた様に、全てのLinux用ライブラリが、この辺の空気を読んでいる訳でもないのが界隈の現状かもしれない今日この頃だ。