为什么会有`/ lib`和`/ lib64`但只有`/ bin`?


27

在我的笔记本电脑中:

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

x86和有两个不同的文件夹x86_64

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

为什么二进制文件只存在一个目录?

PS我也对Android感兴趣,但我希望答案应该相同。


1
只有一个?我看到那里/bin/sbin那里。有什么问题 您是在询问/lib和之间的区别/lib64吗?
库桑兰达

2
@Kusalananda,我的意思是没有独立的文件夹x86_64(都/bin没有/sbin)。
Gluttton

7
IMO OP想知道为什么没有/bin64
Arkadiusz Drabczyk

拥有32位和64位版本(WINE)的大约一个应用程序可以通过使用不同名称的二进制文件(wine*32wine*64)来解决它。
伊格纳西奥·巴斯克斯

1
@ IgnacioVazquez-Abrams:还需要说的是,您将二进制文件链接到库,而不是相反。因此,二进制文件不需要按32/64位分区。
smci

Answers:


25

首先,为什么要分开/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=1ldd包装运行二进制文件,也可以加载哪些库:

$ 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(默认情况下,您当然可以手动编译和部署它)以及目录结构完全不同。


您的ls -l示例并非特别紧密。什么是有用的输出ls -l /lib /lib64,这可能表明,/lib本身就是一个符号链接。
克莱里斯

您的意思是ls -ld,而且不是,/lib这不是我Slackware 14.2系统上的符号链接。
Arkadiusz Drabczyk

库具有不同的md5sum:dfd029d25c58831bc5db671aec99a36f /lib64/libc.so.6987e7b736f316cc8da87ca2f38dae93e /lib/libc.so.6
Arkadiusz Drabczyk

2
在这种情况下,显示目录中的符号链接不会链接到引用。
克莱里斯

1
由于存在安全漏洞,LD_TRACE_LOADED_OBJECTS = 1已过时,ldd不再使用它。原因:ldd / path / to / malicious-static-binary用于接管系统,因为系统管理员希望ldd仅查看二进制文件而不运行它。同样,检查静态与否是否足够,因为可以将二进制文件构造为使用恶意加载程序。
约书亚

22

原因是lib / lib64目录可以包含碰巧具有相同名称的文件,因为这些文件是与各种程序共享的库。将它们放在单独的目录中可以解决冲突。(通常...)没有充分的理由在同一系统上分发32/64位的同名可执行文件,但是由于可执行文件混合在一起,因此必须提供共享库。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.