☰

`/lib` と `/lib64` はあるのに `/bin` だけなのはなぜですか?

tag-icon • tag-icon linux android architecture
`/lib` と `/lib64` はあるのに `/bin` だけなのはなぜですか?

私のラップトップでは:

$ cat /etc/issue  
Ubuntu 18.04 LTS \n \l

ライブラリには 2 つの異なるフォルダーがあります x86。x86_64

~$ ls -1 /  
bin
lib
lib64
sbin
...

バイナリにはなぜディレクトリが 1 つだけ存在するのでしょうか?

追伸：私も Android に興味がありますが、答えは同じであることを願っています。

答え1

/libまず、とが別々に存在する理由は次のとおり/lib64です。

のファイルシステム階層標準 分離して存在する理由について言及してい/libます/lib64:

10.1. 複数のバイナリ形式をサポートし、別々のライブラリを必要とするシステムでは、/lib ディレクトリの 1 つ以上のバリアントが存在する場合があります。(...) これは通常、複数のバイナリ形式をサポートしているが、同じ名前のライブラリを必要とするシステムでの 64 ビットまたは 32 ビットのサポートに使用されます。この場合、/lib32 と /lib64 はライブラリ ディレクトリであり、/lib はそれらの 1 つへのシンボリック リンクである可能性があります。

たとえば、私の Slackware 14.2 には、FHS スニペットが示唆するようなシンボリック リンクではない にもかかわらず、それぞれ 32 ビット ライブラリと 64 ビット ライブラリ用のディレクトリ /libがあります。/lib64/lib

$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib/libc.so.6 -> libc-2.23.so
$ ls -l /lib64/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 11  2016 /lib64/libc.so.6 -> libc-2.23.so

とlibc.so.6には 2 つのライブラリがあります。/lib/lib64

それぞれ動的に構築された ELFバイナリ インタープリターへのハードコードされたパスが含まれます。この場合は または のいずれか/lib/ld-linux.so.2です/lib64/ld-linux-x86-64.so.2。

$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, not stripped
$ readelf  -a main  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib/ld-linux.so.2]

$ file ./main64
./main64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
$ readelf  -a main64  | grep 'Requesting program interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

インタプリタの仕事は、必要な共有ライブラリをロードすることです。バイナリLD_TRACE_LOADED_OBJECTS=1やlddラッパーを使用せずに、GNU インタプリタにどのライブラリをロードするかを問い合わせることができます。

$ LD_TRACE_LOADED_OBJECTS=1 ./main
        linux-gate.so.1 (0xf77a9000)
        libc.so.6 => /lib/libc.so.6 (0xf760e000)
        /lib/ld-linux.so.2 (0xf77aa000)
$ LD_TRACE_LOADED_OBJECTS=1 ./main64
        linux-vdso.so.1 (0x00007ffd535b3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f56830b3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f568347c000)

ご覧のとおり、特定のインタープリターはライブラリを探す場所を正確に認識しています。32 ビット バージョンは でライブラリを探し/lib、64 ビット バージョンは でライブラリを探します/lib64。

FHS 規格では、次のことが規定されています/bin。

/bin には、システム管理者とユーザーの両方が使用できるコマンドが含まれていますが、他のファイルシステムがマウントされていない場合 (シングル ユーザー モードなど) に必要です。また、スクリプトによって間接的に使用されるコマンドも含まれている場合があります。

私の考えでは、 と が別々に存在しない理由は/bin、/bin64これらのディレクトリの両方に同じ名前のファイルがある場合、/binまたは を/bin64の先頭に 置く必要があるため、間接的にどちらかを呼び出すことができないためです$PATH。

ただし、上記は単なる慣例であることに注意してください。Linux カーネルは、 と が別々であるかどうかを実際には気にしません/bin。/bin64必要な場合は、 を作成し、それに応じてシステムを設定できます。

Android についても触れられていますが、修正された Linux カーネルを実行すること以外は、Ubuntu などの GNU システムとは何の関係もありません。glibc も bash もありません (デフォルトでは、もちろん手動でコンパイルして展開できます)。また、ディレクトリ構造も完全に異なります。

答え2

その理由は、lib/lib64ディレクトリに同じ名前のファイルが含まれている可能性があるためです。名前これらはさまざまなプログラムで共有されるライブラリであるためです。これらを別のディレクトリに配置すると、競合は解決されます。(通常は...) 同じ名前の実行可能ファイルを 32/64 ビットの同じシステムに配布する正当な理由はありませんが、実行可能ファイルが混在する可能性があるため、共有ライブラリを提供する必要があります。

関連情報