¿Qué hace que los programas OSX no sean ejecutables en Linux?

40

Sé que hay muchas diferencias entre OSX y Linux, pero ¿qué los hace tan totalmente diferentes, que los hace fundamentalmente incompatibles?

linux osx executable compatibility Falmarri
fuente
55
Bueno, ¿por qué esperarías que los programas OSX sean ejecutables en Linux? ¿Qué pasa con estos dos sistemas operativos específicos que hace que los mencione en la pregunta, pero no cualquier otro sistema operativo que tampoco pueda ejecutar programas OSX?
wrosecrans
66
Esa es básicamente mi pregunta. OSX se ejecuta en un núcleo unix. Me preguntaba qué es lo que lo hace especial en comparación con otros Unix / Linux
Falmarri
66
Hay pequeñas manzanas secretas dentro de los binarios que solo las máquinas Mac pueden ver 
bobobobo
En general, los diferentes sistemas operativos no pueden ejecutar los binarios de cada uno; Es por eso que la práctica de distribuir software como tarballs de origen creció alrededor de Unix. Ni MacOS ni Linux son especiales a este respecto: sería algo especial si alguno pudiera ejecutar los binarios del otro. El comentario más votado que responde al comentario de los wrosecrans está perdiendo totalmente el sentido. : /
Peter Cordes

Respuestas:

56

Todo el ABI es diferente, no solo el formato binario (Mach-O versus ELF) como sepp2k mencionó.

Por ejemplo, si bien Linux y Darwin / XNU (el núcleo de OS X) usan scPowerPC y int 0x80/ sysenter/ syscallen x86 para la entrada de syscall, no hay mucho más en común a partir de ahí.

Darwin dirige los números negativos de syscall en el microkernel Mach y los números positivos de syscall en el kernel monolítico BSD: consulte xnu / osfmk / mach / syscall_sw.h y xnu / bsd / kern / syscalls.master . Los números de syscall de Linux varían según la arquitectura: consulte linux / arch / powerpc / include / asm / unistd.h , linux / arch / x86 / include / asm / unistd_32.h y linux / arch / x86 / include / asm / unistd_64.h - pero todos son no negativos. Entonces, obviamente, los números de syscall, los argumentos de syscall e incluso qué syscall existen son diferentes.

Las bibliotecas de tiempo de ejecución estándar de C también son diferentes; Darwin hereda principalmente la libc de FreeBSD, mientras que Linux generalmente usa glibc (pero hay alternativas, como eglibc y dietlibc y uclibc y Bionic).

Sin mencionar que toda la pila de gráficos es diferente; ignorando todas las bibliotecas de Cocoa Objective-C, los programas GUI en OS X hablan con WindowServer a través de puertos Mach, mientras que en Linux, los programas GUI generalmente hablan con el servidor X a través de sockets de dominio UNIX utilizando el protocolo X11. Por supuesto que hay excepciones; puede ejecutar X en Darwin, y puede omitir X en Linux, pero las aplicaciones OS X definitivamente no hablan X.

Como el vino, si alguien pone el trabajo en

  • implementar un cargador binario para Mach-O
  • atrapar cada llamada al sistema XNU y convertirla en llamadas al sistema Linux apropiadas
  • escribir reemplazos para bibliotecas OS X como CoreFoundation según sea necesario
  • escribir reemplazos para servicios de OS X como WindowServer según sea necesario

entonces podría ser posible ejecutar un programa OS X "nativamente" en Linux. Hace años, Kyle Moffet trabajó en el primer elemento, creando un prototipo binfmt_mach-o para Linux, pero nunca se completó, y no conozco otros proyectos similares.

(En teoría, esto es bastante posible, y se han hecho esfuerzos similares muchas veces; además de Wine, Linux tiene soporte para ejecutar binarios de otros UNIX como HP-UX y Tru64, y el proyecto Glendix tiene como objetivo llevar la compatibilidad del Plan 9 a Linux.)

¡Alguien se ha esforzado por implementar un cargador binario Mach-O y un traductor API para Linux!

shinh / maloader: GitHub adopta el enfoque tipo Wine de cargar el binario y capturar / traducir todas las llamadas de la biblioteca en el espacio de usuario. Ignora por completo las llamadas al sistema y todas las bibliotecas relacionadas con gráficos, pero es suficiente para que funcionen muchos programas de consola.

Darling se basa en el maloader, agregando bibliotecas y otros bits de tiempo de ejecución compatibles.

efímero
fuente
Es mucho más probable que los nuevos esfuerzos utilicen binfmt_misc que tener cualquiera de sus propios códigos de kernel, ¿no?
SamB
@SamB: ¿Alguna vez has intentado configurar un controlador binfmt_misc en un chroot? Creo que es bastante razonable manejar formatos binarios para otros sistemas similares a UNIX en el núcleo.
Ephemient
1
Mi pregunta es; Si tiene binarios de OS X para ejecutar en Linux, ¿por qué necesitaría reescribir las bibliotecas y servicios de OS X? ¿No se ejecutarían sin cambios en Linux en ese momento? ¿Se trata solo de cuestiones legales?
Hubro
20

Por qué las aplicaciones OSX no se ejecutarán de forma nativa en Linux:

En primer lugar, OSX usa un formato binario diferente que Linux, por lo que Linux no puede ejecutar archivos binarios compilados para OSX (de la misma manera que no puede ejecutar archivos binarios compilados para Windows o BSD).

En segundo lugar, si habla de aplicaciones GUI, el kit de herramientas GUI de Apple Cocoa a) solo está disponible para OSX yb) no se ejecuta sobre X11.

Por qué no hay equivalente de wine para aplicaciones OSX:

Había que hacer mucho trabajo antes de que el vino fuera utilizable hasta la mitad. Como no hay tanta demanda de un equivalente de OSX, nadie ha invertido la misma cantidad de esfuerzo en dicho proyecto todavía.

sepp2k
fuente
Sabes, ni siquiera me di cuenta de que OSX / unix no usaba el mismo formato binario. ¿Tienes un enlace a más información sobre eso?
Falmarri
Falmarri: OSX usa el formato Mach-O , Linux usa ELF .
sepp2k
1
@Falmarri No todos los UNIX usan el mismo formato binario, y aunque casi todos los modernos usan ELF, generalmente no puede ejecutar un binario de un UNIX en otro. Diablos, no creo que FreeBSD incluso garantice que puedas ejecutar un programa para 7.x en 8.xo viceversa, mientras que un programa de Linux para 1.0 aún debería ejecutarse en 2.6.x.
Ephemient
5

La razón más importante por la que las aplicaciones OS X no se ejecutarán en Linux es porque esos sistemas operativos utilizaron diferentes llamadas al sistema.

Algunas respuestas anteriores mencionaron bibliotecas, pero ese no es generalmente el caso: Core Foundation es en gran parte de código abierto por Apple con el nombre CFLite y es fácilmente portátil para cualquier plataforma (la versión de Windows de iTunes en realidad se encuentra encima de un puerto de Windows de Core Foundation, y con algunos ajustes del compilador, puede hacer CFLite directamente usando clang en una distribución de Linux) y también hay esfuerzos de código abierto para portar el entorno Objective-C, principalmente Foundation y AppKit a Linux, especialmente GNUstep, una implementación GNU de OpenStep, que data anterior a Apple's Cocoa (comenzó cuando todavía existía la empresa NeXT Computer).

Si alguien está determinado, pueden diseñar un cargador que capturará cada llamada al sistema de Mach-O y la traducirá a la llamada al sistema Linux correspondiente, así como también vincular dinámicamente esas "contrapartes" de la biblioteca de código abierto al binario con la traducción ABI adecuada.

Y solo para su información, si puede obtener el código fuente de la aplicación Mach-O, puede considerar portarlo y puede resultar muy simple. Como ejemplo, la aplicación TextEdit incluida con OS X 10.6 puede recompilarse directamente con GNUstep después de quitar algunas líneas de código CF (no crítico) y, por lo tanto, inmediatamente disponible en Linux (sin mencionar que TextEdit enviado con GNUstep era en realidad un recompilación directa de la aplicación TextEdit de NeXTSTEP, el precursor de OS X también, incluso conservando su etiqueta "© 1995 NeXT"). TextEdit está bajo licencia BSD.

Maxthon Chan
fuente