☰

Mac OS X와 ​​Linux 간의 바이너리 호환성

tag-icon • tag-icon linux executable programming
Mac OS X와 ​​Linux 간의 바이너리 호환성

비슷한 하드웨어를 갖춘 두 개의 시스템이 있습니다(표준 Intel Core 2 Duo와 같은 프로세서에 중점을 둡니다).

하나는 실행 중이고(지금부터 Linux 배포판을 여기에 삽입: Ubuntu) 다른 하나는 실행 중입니다(Mac OS X로 가정).

동등한 프로그램을 컴파일하려면 다음과 같이 해보자:

int main()
{
    int cat = 33;
    int dog = 5*cat;
    return dog;
}

공유 라이브러리에 대한 의미를 아직 생각하고 싶지 않기 때문에 코드는 매우 간단합니다.

해당 시스템에서 컴파일할 때. 출력의 주요 차이점은 ELF와 Mach-O의 문제가 아닌가요? 각 바이너리의 형식을 제거하고 플랫 바이너리만 남겨둔다면 디스어셈블된 기계어 명령어는 동일하지 않을까요? (컴파일러 습관/성향에 따라 약간의 차이가 있을 수 있습니다.)

  1. Ubuntu 시스템에서 생성된 플랫 바이너리를 Mach-O 형식으로 다시 패키지하는 프로그램을 개발하려는 경우 Mac OS X 시스템에서 실행됩니까? 그렇다면 위 프로그램의 컴파일된 바이너리만 있고 플랫 바이너리를 다시 패키징하는 신비한 도구가 있다면 간단한 프로그램이 Mac OS X 시스템에서 실행될 수 있을까요?

이제 한 단계 더 나아가 보겠습니다.

이제 다음과 같은 소스 코드를 가진 프로그램이 생겼습니다.

#include <stdio.h>
int main()
{
    printf("I like tortoises, but not porpoises");
    return 0;
}
  1. 이 프로그램이 컴파일되고 정적으로 링크되었다고 가정하면, 우리의 마법 프로그램이 원래 바이너리를 Mach-O 형식으로 다시 패키지하여 Mac OS X에서 실행할 수 있습니까? 다른 바이너리에 의존할 필요가 없기 때문입니다(이 경우 Mac 시스템은 다른 바이너리에 의존할 필요가 없습니다).

이제 마지막 단계로 넘어갑니다.

  1. 이 가상 프로그램을 사용하여 필요한 모든 공유 라이브러리를 Mach-O 형식으로 변환한 다음 동적 연결을 사용하여 위 프로그램을 컴파일하면 어떻게 될까요? 프로그램이 계속해서 성공적으로 실행되나요?

이제 각 단계의 부조리가 이해되기까지 이전 기반에 의존한다는 것이 명백해졌습니다. 따라서 첫 번째 기둥이 파괴되면 나머지 층의 가치가 그다지 높지 않을 것입니다.

나는 GUI가 있는 프로그램에 대해 이것을 결코 생각하지 않을 것입니다. 윈도우 시스템은 또 다른 골칫거리가 될 수 있습니다. 이 단계에서는 명령줄 프로그램만 고려하고 있습니다.

이제 나는 세상 사람들에게 나를 바로잡고 나의 터무니없는 생각의 모든 오류를 말해 달라고 요청합니다.

답변1

흥미로운 일을 하려면 프로그램이 운영 체제와 상호 작용해야 한다는 중요한 사실을 잊고 있습니다.

Linux와 OS X의 규칙은 서로 다르기 때문에 상호 작용할 OS별 코드가 많이 없으면 동일한 바이너리가 있는 그대로 실행되지 않습니다. 이런 것들은 대부분 라이브러리를 통해 제공되는데, 라이브러리에 링크를 걸어야 하는데, 이는 프로그램이 링크 가능해야 하고, 두 시스템 간의 링크도 다르다는 뜻입니다.

이런 식으로 진행됩니다. 표면적으로는 같은 일을 하는 것처럼 들리지만 실제 세부 사항은 매우 다릅니다.

답변2

누군가 이것을 구현하는 데 충분한 시간을 투자하고 싶다면 가능합니다. 이것친애하는 계획글을 쓰는 시점에서는 상당히 원시적인 상태이지만 그렇게 하려는 시도가 이루어지고 있습니다.

이 작업은 이전에 다른 플랫폼에서 성공적으로 수행되었습니다.

  • Solaris 및 UnixWare에는 다음과 같은 도우미가 포함되어 있습니다.lxrun이는 다음과 같이 작동합니다 sudo. 실행 파일 이름과 매개변수를 도우미 프로그램에 전달하면 실행 파일이 운영 체제와 통신할 수 있도록 즉시 문제를 수정합니다. 이것공식 웹 사이트(아래에,아카이브 링크)이렇게 말했어조금 썩은.

  • Linux 커널에는 한때 다음과 같은 기능이 있었습니다.iBCS커널이 "외부" 바이너리를 직접 인식하기 때문에 도우미가 필요하지 않다는 점을 제외하면 정반대입니다. 그것커널 2.3 개발 시리즈 중 파손에 빠지다, 아마도 2.4 릴리스 이후 소규모 Unix 서버 전쟁이 본질적으로 끝났기 때문일 것입니다.

  • FreeBSD 커널Linux 바이너리를 인식하도록 구성 가능네이티브처럼 실행하세요. 이 기능은 위의 두 가지 기능보다 더 나은 것 같습니다.

    OpenBSD와 NetBSD는 비슷한 기능을 가지고 있습니다.

OS X에는 FreeBSD가 많이 있습니다., 따라서 Linux 지원을 포팅하는 것은 간단할 수 있습니다.

답변3

나는 확실히 모든 사람의 의견에 동의하지만, 여기에는 많은 시간과 노력이 필요하지만 와인을 개발하는 것만큼 많지는 않을 것이라는 점을 덧붙이고 싶습니다.

Wine 개발에서 가장 어려운 점은 폐쇄 소스 운영 체제에서 바이너리 형식을 이식하고 많은 시스템 호출이 문서화되지 않았다는 것입니다. 그들은 본질적으로 운영 체제를 리버스 엔지니어링해야 합니다.

누군가가 하나의 개방형 운영 체제에서 다른 운영 체제로 이 작업을 수행한다면 아마도 시간의 1/10 안에 완료할 수 있을 것입니다. 왜냐하면 동등한 기본 시스템 호출이 있다면 아마도 다른 운영 체제에서 호환성 계층을 가질 수 있기 때문입니다. 운영 체제 복사/붙여넣기 존재하지 않는다. 물론 POSIX 세계에서는 대부분의 경우 기본 호출을 사용할 수 있습니다.

또 다른 주목할만한 프로젝트는 ReactOS입니다. 이 프로젝트는 본질적으로 Wine이 필요 없는 Windows의 완전히 바이너리 호환 버전을 만들고 있습니다.

답변4

큰 도움이 될 전문적인 Linux 애플리케이션이 많이 있습니다. FPGA 측면에서 Quartus와 Vivado는 Linux에서 실행되는 프로그램의 좋은 예이지만 최신 FPGA에 대한 소스 코드나 유사한 프로그램을 사용할 수 있을 가능성은 낮습니다.

귀하의 질문에 대한 간단한 대답은 소스 코드가 있는 MacOS에서 다시 컴파일하고, 시간이 있으면 팀을 구성하여 기능을 제공하는 것입니다. 이는 시간이 많이 걸리는 작업이 될 것입니다.

관련 정보