Linux에서 OSX 프로그램을 실행할 수없는 이유는 무엇입니까?

나는 OSX와 Linux 사이에 많은 차이점이 있다는 것을 알고 있지만, 완전히 다른 점은 무엇이 근본적으로 호환되지 않습니까?

sepp2k에서 언급 한 것처럼 이진 형식 (Mach-O 대 ELF)만이 아니라 전체 ABI 가 다릅니다.

예를 들어, 리눅스, 다윈 / XNU (OS X의 커널) 모두 사용하면서 sc파워 온 int 0x80/ sysenter/ syscall콜 항목 86에이 훨씬 더 공통점이 아니다에 거기에서.

다윈은 Mach 마이크로 커널에서 음수의 syscall 수를, BSD 모 놀리 식 커널에서 양의 syscall 수를 지시합니다 (xnu / osfmk / mach / syscall_sw.h 및 xnu / bsd / kern / syscalls.master 참조) . Linux의 시스템 콜 번호는 아키텍처에 따라 다릅니다. linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h 및 linux / arch / x86 / include / asm / unistd_64.h를 참조하십시오. — 그러나 모두 음이 아닙니다. 따라서 분명히 syscall 번호, syscall 인수 및 존재 하는 syscall도 다릅니다.

표준 C 런타임 라이브러리도 다릅니다. 다윈은 대부분 FreeBSD의 libc를 상속받는 반면 리눅스는 일반적으로 glibc를 사용합니다 (eglibc와 dietlibc, uclibc, Bionic과 같은 대안이 있습니다).

전체 그래픽 스택이 다르다는 것은 말할 것도 없습니다. 전체 Cocoa Objective-C 라이브러리를 무시하면 OS X의 GUI 프로그램은 Mach 포트를 통해 WindowServer와 통신하지만 Linux의 경우 GUI 프로그램은 일반적으로 X11 프로토콜을 사용하여 UNIX 도메인 소켓을 통해 X 서버와 통신합니다. 물론 예외가 있습니다. Darwin에서 X를 실행할 수 있고 Linux에서는 X를 무시할 수 있지만 OS X 응용 프로그램은 X와 대화하지 않습니다.

와인처럼 누군가가 작업을한다면

• Mach-O 용 바이너리 로더 구현
• 모든 XNU syscall을 트래핑하여 적절한 Linux syscall로 변환
• 필요에 따라 CoreFoundation과 같은 OS X 라이브러리에 대한 대체 쓰기
• 필요에 따라 WindowServer와 같은 OS X 서비스에 대한 대체 문서 작성

Linux에서 "원시"OS X 프로그램을 실행할 수 있습니다. 몇 년 전 Kyle Moffet은 첫 번째 항목에 대한 작업을 수행하여 Linux 용 프로토 타입 binfmt_mach-o 를 만들었지 만 아직 완료되지 않았으며 다른 유사한 프로젝트는 없습니다.

이론 상으로는 이것이 가능하고 유사한 노력이 여러 번 이루어졌다. Wine 외에도 Linux 자체는 HP-UX 및 Tru64와 같은 다른 UNIX에서 바이너리를 실행할 수 있도록 지원하며 Glendix 프로젝트는 Plan 9 호환성을 목표로한다 리눅스)

누군가가 있다 Linux 용 마하-O 바이너리 로더와 API 번역기를 구현하기위한 노력에 넣어!

shinh / maloader-GitHub 는 바이너리를로드하고 사용자 공간에서 모든 라이브러리 호출을 트래핑 / 번역하는 와인과 같은 접근 방식을 취합니다. syscall과 모든 그래픽 관련 라이브러리를 완전히 무시하지만 많은 콘솔 프로그램이 작동하기에 충분합니다.

Darling 은 maloader를 기반으로 라이브러리 및 기타 지원 런타임 비트를 추가합니다.

OSX 애플리케이션이 Linux에서 기본적으로 실행되지 않는 이유 :

우선 모든 OSX는 Linux와 다른 이진 형식을 사용하므로 Linux는 OSX 용으로 컴파일 된 이진 파일을 실행할 수 없습니다 (Windows 또는 BSD 용으로 컴파일 된 이진 파일을 실행할 수없는 것과 동일).

둘째, GUI 응용 프로그램에 대해 이야기하고 있다면 Apple의 GUI 툴킷 Cocoa a)는 OSX에서만 사용할 수 있으며 b) X11 위에서 실행되지 않습니다.

OSX 애플리케이션에 해당하는 와인이없는 이유 :

와인을 반 정도 사용하기 전에 많은 작업을 수행해야했습니다. OSX에 대한 수요는 많지 않기 때문에 아직 그러한 프로젝트에 동일한 노력을 투자 한 사람은 없습니다.

OS X 앱이 Linux에서 실행되지 않는 가장 중요한 이유는 해당 OS가 서로 다른 syscall을 사용했기 때문입니다.

이전의 일부 답변은 라이브러리를 언급했지만 일반적으로 그렇지 않습니다 .Core Foundation은 Apple에서 CFLite라는 이름으로 오픈 소스를 제공하며 모든 플랫폼으로 쉽게 이식 할 수 있습니다 (iTunes의 Windows 버전은 실제로 Core Foundation의 Windows 포트 위에 있으며 일부 컴파일러 조정, Linux 배포판에서 clang을 사용하여 CFLite를 직접 만들 수 있음) Objective-C 환경, 주로 Foundation 및 AppKit을 Linux, 특히 OpenStep의 GNU 구현 인 GNUstep으로 포팅하려는 오픈 소스 노력도 있습니다. 애플의 코코아 이전 (여전히 NeXT Computer가있을 때 시작)

누군가가 결정되면 모든 Mach-O syscall을 캡처하고이를 해당 Linux syscall로 변환하고 해당 오픈 소스 라이브러리 "counterparts"를 적절한 ABI 변환을 사용하여 바이너리에 동적으로 링크하는 로더를 설계 할 수 있습니다.

정보를 위해 Mach-O 응용 프로그램의 소스 코드를 얻을 수 있다면 포트를 고려하면 매우 간단 할 수 있습니다. 예를 들어, OS X 10.6에 번들로 제공되는 TextEdit 앱은 중요하지 않은 CF 코드 몇 줄을 제거한 후 GNUstep에 대한 링크를 직접 다시 컴파일하여 Linux에서 즉시 사용할 수 있습니다 (GNUstep과 함께 제공된 TextEdit는 말할 것도없고 OS X의 선구자 인 NeXTSTEP의 TextEdit 앱을 직접 다시 컴파일하고 "© 1995 NeXT"레이블을 유지합니다). TextEdit은 BSD 라이센스하에 있습니다.

2012 년 12 월 8 일 Darling이라는 새로운 프로젝트가 시작되었습니다.

http://www.darlinghq.org/