首先,为什么要分开/lib
和/lib64
:
该文件系统层次标准
中提到,独立/lib
和/lib64
存在是因为:
10.1。在系统上,/ lib目录可能有一个或多个变体,它们支持不止一种需要单独库的二进制格式。(...)通常在支持多种二进制格式但需要同名库的系统上用于64位或32位支持。在这种情况下,/ lib32和/ lib64可能是库目录,而/ lib是其中一个的符号链接。
例如,在我的Slackware 14.2上,分别有
32位和64位库的/lib
和/lib64
目录,即使
/lib
它不是FHS代码段所建议的符号链接:
$ 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
图书馆/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]
解释器的工作是加载必要的共享库。您可以询问GNU解释器,即使不使用LD_TRACE_LOADED_OBJECTS=1
或ldd
包装运行二进制文件,也可以加载哪些库:
$ 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包含可由系统管理员和用户使用的命令,但是在未安装其他文件系统时(例如在单用户模式下),这些命令是必需的。它还可能包含脚本间接使用的命令。
IMO为什么没有单独的原因/bin
,并/bin64
是,如果我们有文件在这两个目录的名称相同,我们不能给他们打电话的一个间接原因,我们不得不把/bin
或/bin64
在第一
$PATH
。
但是,请注意,以上仅是约定-Linux内核实际上并不关心是否有单独的/bin
和/bin64
。如果需要它们,可以创建它们并相应地设置系统。
您还提到了Android-注意,除了运行经过修改的Linux内核外,它与Ubuntu等GNU系统无关-没有glibc,没有bash(默认情况下,您当然可以手动编译和部署它)以及目录结构完全不同。
/bin
和/sbin
那里。有什么问题 您是在询问/lib
和之间的区别/lib64
吗?