web-dev-qa-db-ja.com

クロスプラットフォームアプリケーションで「ファットバイナリ」が広く使用されないのはなぜですか？

私の知る限りでは、いわゆる「ファットバイナリ」（複数のシステムのマシンコードを含む実行可能ファイル）は、実際にはApple PCでのみ使用されます。 PowerPCからx86への移行が必要だったため、それらのみを使用しました。

最近、ソフトウェアのlotはクロスプラットフォームであり、単一のファットバイナリを作成することは、多くの点で、ダースを追跡するよりも簡単なようです。または、オペレーティングシステムとアーキテクチャの組み合わせごとに異なるダウンロードを使用します。言うまでもなく、顧客にどのダウンロードが必要かを伝えます。

たとえば、このアプローチがうまくいかなかった理由について、多くの推測を思い付くことができます。

  • マルチOSバイナリを実行不可能にするクロスコンパイルツールの欠如
  • とにかく、各OSでコードをテストする必要があるため、各OSに対してネイティブにコンパイルできるシステムがすでに必要です。
  • どうやら32ビットのプログラムはすでに64ビットのマシンで「ちょうど動く」ようです
  • ダイナミックリンクはOSごとに動作が異なるため、「ファットアプリケーション」が機能しても、「ファットライブラリ」は機能しない場合があります。

しかし、私は常にこれらのOS固有およびアーキテクチャ固有の詳細をすべて隠すライブラリまたはフレームワークを使用しているので、それがどれほど本当であるか、またはさらに多くの問題があるかどうかわからない約。それで、ファットバイナリがマルチアーキテクチャおよび/またはマルチOSソフトウェアを作成するために一般的に使用されない実際の理由は何ですか？（アップル以外）

operating-systemscross-platformbinary
28
Ixrec

ファットバイナリアプローチは、次の場合に最も意味があります。

  1. 両方のアーキテクチャが同じシステムに共存している
  2. 他のすべては、すべてのアーキテクチャでほぼ同じです

クロスプラットフォームコード（両方の基準は適用されません）、または異なるLinuxディストリビューションを1つのバイナリでサポートするために使用されないのはそのためです（1.は適用されません） 、2。ある程度適用されます）。

Linuxでは、両方をサポートする場合、両方の基準が適用されます単一のLinuxディストリビューションで32ビットと64ビット。しかし、すでに複数のディストリビューションをサポートする必要があるのなら、なぜわざわざ？

Windowsでは、16ビットから32ビットへの移行は、最初にWindows NTが導入されたときに発生しました。これは、多くの点（仮想メモリ、マルチユーザーアクセス制御、 APIの変更...）。これらすべての変更により、32ビットと16ビットの世界を分離しておく方が良かった。 NTにはすでに「サブシステム」の概念がさまざまなOS「ペルソナ」（Win32、POSIX）をサポートしていたため、Win16を3番目のサブシステムにすることは簡単な選択でした。

Win32からWin64への移行には、同様の大きな変更は含まれていませんでしたが、Microsoftはいずれにせよ、同様のアプローチを使用しました。

10
oefe

インターネット年齢分布ロジスティックスは、次の2つの方法でファットバイナリを無力化します。

  1. POSは物理的な商品を含まないため、製品が小売店の棚スペースをめぐって競合し、顧客が購入する機会が限られている場合のように、SKUの数は少なくなります。

  2. 帯域幅のコストは、特定のソフトウェアパッケージに必要な最小限のビットを提供することを優先します。ファットバイナリを送信すると、カスタマーエクスペリエンスとセラーインフラストラクチャの効率の両方が低下します。

ソフトウェアがシュリンクラップされた物理メディアである場合、ファットバイナリはより理にかなっています。

12
ben rudgers

ファットバイナリが成功しなかった理由の一部は [〜＃〜] abi [〜＃〜] ＆ processor （実際には 命令セット ）バイナリ実行可能ファイルを無効にする指定。バイナリ実行可能ファイルは、他のリソース、特に ダイナミックライブラリ （ DLL hell を参照）、外部サービス（DBMSのような PostGreSQL = ....）、システム構成（Linuxの/etc/での構成ファイルの場所など）など...

Linux/x86-64の場合のみ、バイナリ実行可能ファイルをすべてのLinuxディストリビューションで実行できるようにすることは実際には困難です（多くの場合、特定のバージョンのlibcまたはlibstdc++に関連付けられているため）。 FatELF は存在しますが、あまり成功していません。

明確に定義されたABIと命令セットを使用しても、最適化はさまざまなプロセッサブランドで異なります--mtune=nativex86最適化[〜＃〜] gcc [〜 ＃〜] 。

アップルは、コンピューティングリソースの非常に閉鎖的なエコシステムを提供しているという理由だけで、脂肪バイナリを部分的に持つことに成功しました。

フリーソフトウェア は、移植性の問題を解決するもう1つの方法です。アプリケーションがフリーソフトウェア（移植性のために注意深くコーディングされている）であれば、同様のシステムに非常に簡単に移植できます。また、元のソースコードがシステムで意図したとおりに機能しない場合でも、通常は簡単にそれを適応させる（または誰かに作業を依頼する）ことが簡単にできます（もちろん、特定のOSまたはABIまたはプロセッサに関連付けられた無料のソフトウェアは簡単ではありませんポート、あなたはそのためのより多くの努力を払うでしょう）。 [〜＃〜] posix [〜＃〜] または Linux Standard Base のような標準も役立ちます。

誰かにお金を払う（または頼む）ことで、（無料の）ソフトウェアを利用可能なソースコードで移植することができますが、バイナリ実行可能ファイルを移植することは現実的ではありません。

最後に、いくつかのフレームワークは、いくつかのオペレーティングシステムへの移植を支援するために存在します（ソースコードが利用可能である場合）。 Qt ＆ [〜＃〜] poco [〜＃〜] 。

[〜＃〜] jvm [〜＃〜] のような適切に指定されたバイトコードを使用しても、必ずしも移植性が保証されるわけではありません。一部のJavaアプリケーションは、移植性がない（たとえば、特定のファイル階層と命名を期待しているため）。

ちなみに、今日のコンピュータシステムは、1980年代や1990年代初頭（またはメインフレーム時代）に比べて、おそらくそれほど異機種混在ではありません。

ついに、ファットバイナリはファットです。多くの人に関係しない移植性の問題のために、多くのリソース（ビルド時間、帯域幅、実行可能サイズ）を費やすことになります。 「一部の特定のシステムに）「移植可能なソフトウェアはなく、移植されたソフトウェアのみ」という格言を覚えておいてください。

2
Basile Starynkevitch