*nix 실행 파일 호환성

짧은 대답: 아니요.

보통 수준의 답변: 대상 운영 체제에서 지원한다면 그럴 수도 있습니다.

답변이 길군요...

가장 먼저 주목해야 할 점은 공급업체마다 서로 다른 칩셋을 사용할 수 있다는 것입니다. 따라서 Solaris 바이너리는 SPARC 칩용으로 컴파일될 수 있습니다. Intel/AMD 시스템에서는 작동하지 않습니다. 마찬가지로 AIX도 PowerPC에 있을 수 있습니다. HP-UX는 PA-RISC에 있을 수 있습니다. 이 모든 문제를 무시하고 "Intel/AMD" 공간에만 집중하겠습니다.

다음 문제는 서로 다른 운영 체제가 서로 다른 커널을 노출할 수 있다는 것입니다.시스템 호출. 이는 애플리케이션에 의한 커널 호출이 예상대로 작동하지 않음을 의미합니다. 이것은 분명히 문제입니다. 그러나 대상 커널가능한"ABI 호환성 계층"을 제공하는 기능, 커널(FreeBSD 커널 가정)은 Linux 바이너리를 실행하려고 한다는 것을 감지하고 Linux 커널 ABI와 기본 커널 ABI 간에 변환할 수 있습니다.

이것다음문제는 라이브러리 중 하나입니다. Linux 바이너리는 호스팅 운영 체제에 없을 수 있는 특정 버전의 glibc를 로드할 수 있을 것으로 예상합니다. 이것가능한이 문제는 필요한 라이브러리를 복사하여 해결할 수 있습니다. 다시 말하지만, 운영 체제는 이러한 라이브러리를 쉽게 설치할 수 있도록 패키지를 제공하는 등 이를 더 쉽게 만들 수 있습니다.

모든 바이너리 후에가능한달리기:-)

1990년대에 Linux에는 이러한 작업을 가능하게 하는 iBCS 모듈이 있었습니다. 예를 들어 Linux에서 SCO Unix 프로그램을 실행할 수 있습니다. 개념 증명으로 내 컴퓨터에서 SCO Unix Oracle을 실행했습니다. 효과는 매우 좋습니다! 분명히 공급업체 지원이 없으므로 프로덕션에 적합하지 않습니다. :-)

이제 Linux는 이 분야에서 큰 발판을 마련하게 되었고, 다른 운영 체제에서는 Linux 프로그램이 해당 운영 체제에서 실행될 수 있도록 호환성 계층을 추가하려고 노력하고 있습니다.

따라서 운영 체제가 지원하는 경우그리고올바르게 설치하고 구성하면가능한다른 Unix에서 일부 프로그램을 실행하는 능력.

아니요, 대부분의 경우 실행 파일은 실행되지 않습니다.동일한커널 변경으로 인해 운영 체제 버전이 달라졌습니다.

일전에 제가 본 간단한 예는 dmesgOpenBSD의 명령이 모든 커널 메시지(부팅 정보 등)가 가는 시스템 메시지 버퍼를 출력한다는 것입니다. 최근에 커널을 다시 컴파일했는데 갑자기 다음 dmesg과 같이 돌아왔습니다.

dmesg: sysctl: KERN_MSGBUF: Cannot allocate memory

이는 userland 유틸리티가 재컴파일되지 않고 dmesg실행 파일이 해당 작업을 수행할 수 없다는 의미에서 "작업 중"으로 인식되기 때문입니다(커널 코드 변경으로 인해).

따라서 dmesg이전 버전은 최신 운영 체제에서 "작동"하지 않습니다.

편집하다(댓글의 댓글, 추가 사항 포함)

커널의 시스템 호출을 API로 생각하십시오. API를 변경할 수 없거나 이전 버전과의 호환성을 항상 유지해야 한다면 이는 무엇을 의미합니까? 이는 설계 결함이 아니라 소프트웨어가 작동하는 일반적인 방식입니다.

한 API 버전에 대해 컴파일된 실행 코드가 해당 API의 다른 버전에서 작동할 것이라고 기대할 수는 없습니다. API/커널 개발자로서 당신은 OS를 추가하고 개선하는 것보다 이전 버전과의 호환성을 깨뜨리는 것에 더 관심을 가질 것입니다.

다행스럽게도 Unix 시스템의 대부분의 소프트웨어는 POSIX 표준에 따라 설계되었습니다.원천실행 파일의 내용은 시스템 유형 간에 전송될 수 있으며 거의 ​​모든 곳에서 컴파일하고 실행할 수 있습니다. Unix 플랫폼 간의 바이너리 호환성 문제는 다음과 같은 경우에만 문제가 됩니다.

• 비 POSIX 확장이 필요하며
• 소스코드는 비공개 소스입니다.