왜`/ lib`와`/ lib64`가 있고`/ bin` 만 있는가?

내 노트북에서 :

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

라이브러리 x86와 폴더에는 서로 다른 두 개의 폴더가 있습니다 x86_64.

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

바이너리에 왜 하나의 디렉토리 만 존재합니까?

추신 : 나는 안드로이드에도 관심이 있지만 대답이 똑같기를 바랍니다.

linux android architecture

— 글루 턴
소스

하나만? 나는 둘 다 /bin보고 /sbin있다. 질문이 무엇입니까? 당신의 차이에 대해 묻는 /lib와 /lib64?

— Kusalananda

@Kusalananda, 나는에 대한 독립적 인 폴더가 없음을 의미한다 x86_64(도에 대한 /bin없음 /sbin).

— Gluttton

IMO OP는 왜 없는지 알고 싶어합니다 /bin64.

— Arkadiusz Drabczyk 2016 년

32 비트 및 64 비트 버전 (WINE)을 모두 사용하여 얻을 수있는 약 하나의 응용 프로그램은 다른 이름의 이진 ( wine*32및 wine*64)을 사용하여 문제를 해결합니다.

— Ignacio Vazquez-Abrams

@ IgnacioVazquez-Abrams : 또한 바이너리를 라이브러리에 연결하는 것이 아니라 그 반대의 경우도 필요합니다. 따라서 바이너리는 32/64 비트로 분할 할 필요가 없습니다.

— smci

첫째, 왜 분리되어 /lib있고 /lib64:

파일 시스템 계층 표준은 그 별도의 언급 /lib과 /lib64존재하기 때문에 :

10.1. 별도의 라이브러리가 필요한 둘 이상의 이진 형식을 지원하는 시스템에는 하나 이상의 / lib 디렉토리 변형이있을 수 있습니다. (...) 일반적으로 여러 이진 형식을 지원하지만 동일한 이름의 라이브러리가 필요한 시스템에서 64 비트 또는 32 비트 지원에 사용됩니다. 이 경우 / lib32 및 / lib64는 라이브러리 디렉토리 일 수 있으며 / lib는 그 중 하나에 대한 심볼릭 링크입니다.

내 슬랙웨어 14.2에, 예를 들어 있습니다 /lib및 /lib64 32 비트 및 64 비트 라이브러리 디렉토리는 각각 비록 /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라이브러리 가 있습니다 ./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 비트 버전은 라이브러리를 찾고 /lib64 비트 버전은 라이브러리를 찾습니다 /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그 자체가 심볼릭 링크입니다.

— chrylis

당신은 의미 ls -ld하고, 아니, /lib내에 심볼릭 링크없는 Slackware 14.2시스템입니다.

— Arkadiusz Drabczyk

라이브러리에는 다른 md5sum이 있습니다 : dfd029d25c58831bc5db671aec99a36f /lib64/libc.so.6, 987e7b736f316cc8da87ca2f38dae93e /lib/libc.so.6.

— Arkadiusz Drabczyk 2018 년

이 경우 디렉토리에 심볼릭 링크가 표시되면 인용에 연결되지 않습니다.

— chrylis

LD_TRACE_LOADED_OBJECTS = 1은 보안 허점으로 인해 더 이상 사용되지 않으며 ldd는 더 이상 사용하지 않습니다. 이유 : 시스템 관리자가 ldd / path / to / malicious-static-binary를 사용하여 ldd가 실행하지 않는 바이너리 만 보려고했기 때문에 시스템을 인수했습니다. 또한 바이너리를 악의적 인 로더를 사용하도록 구성 할 수 있기 때문에 정적 여부를 확인하는 것은 적절하지 않습니다.

— Joshua

그 이유는 lib / lib64 디렉토리는 다양한 프로그램과 공유되는 라이브러리이기 때문에 동일한 이름 을 갖는 파일을 포함 할 수 있기 때문입니다. 별도의 디렉토리에두면 충돌이 해결됩니다. 동일한 시스템에 32/64 비트 인 동일한 이름의 실행 파일을 배포 할만한 이유는 없지만 (일반적으로 ...), 실행 파일이 혼합되어있을 수 있으므로 공유 라이브러리를 제공해야합니다.

— 토마스 디키
소스