(이것은 불만 사항이 아닌 일반적인 질문입니다. 이에 대한 좋은 설명이 있을 수 있습니다.)
컴파일된 실행 파일의 경우 운영 체제가 결정하도록 하는 대신 인터프리터 경로를 바이너리로 하드코딩하는 이유는 무엇입니까? 즉, 인터프리터는 실행 파일의 형식(예: 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.
동적 링커의 선택은 공유 라이브러리가 검색되는 방법도 제어하므로 경로를 사용하지 않고 링커 스타일 알고리즘을 사용하여 적절한 링커를 찾지 않고는 이름만으로 동적 링커를 지정하는 것조차 불가능합니다. 또 다른 접근 방식도 가능하지만 커널에서 구현해야 하므로 각 바이너리에 하드코딩하는 것이 훨씬 쉽습니다.
답변2
원하는 표준 경로에 따라 인터프리터를 지정하거나 대신 /usr/bin/env를 사용하십시오. 'nix 시스템에서는 로그인 기록이 있습니다. 대부분의 스크립트 시작 부분에 있는 해시뱅 라인을 살펴보세요. 실제 운영 체제 파일 유형 개념이 없기 때문에 예상되는 경로나 인터프리터 또는 링커를 파일에 넣는 것은 대체된 적이 없는 오래된 표준 솔루션입니다.