（これは苦情ではなく一般的な質問です。これについて良い説明があるかもしれません。）
コンパイルされた実行可能ファイルの場合、オペレーティングシステムが決定するのではなく、インタプリタパスをバイナリにハードコードするのはなぜですか？つまり、インタプリタは実行可能ファイルの形式（ELFなど）やアーキテクチャ（x86-64）から派生してはなりません。
通訳者パスは、次の実行時に表示されますfile /path/to/some-executable。
some-executable: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=acd1829414c2843215bd10ed75a0fe486fce288e, not stripped
インタプリタパス文字列が実際にバイナリに存在するstrings -t x /path/to/some-executable | headことを確認し、バイト0x270：にあるとマークするには、ファイルを270 /lib64/ld-linux-x86-64.so.2チェックするとreadelf -l /path/to/some-executableインタプリタと同じオフセットが表示されます。
ベストアンサー1
利用可能な属性ELFヘッダ(動的リンカー自体へのポインターは除く)いいえ適切な動的リンカーを決定するのに十分です。動的リンカーはコンパイラが構築されたCライブラリにも接続されているため、たとえばGNU Cライブラリで構築されたLinuxの64ビットx86バイナリmusl 動的リンカーによってロードされると失敗します。:
バイナリ互換性はより制限的ですが、新しいバージョンのmuslでは着実に改善されます。現在、一部のglibcリンク共有ライブラリはmuslを使用してロードできますが、muslを
/lib/ld-linux.so.2。
ダイナミックリンカーの選択は、共有ライブラリの検索方法も制御するため、パスを使用せずにリンカースタイルアルゴリズムを使用して適切なリンカーを見つけない限り、名前だけでダイナミックリンカーを指定することもできません。別のアプローチも可能ですが、カーネルで実装する必要があるため、各バイナリにハードコーディングする方がはるかに簡単です。