Compatibilidade binária entre o Mac OS X e o Linux

25

Prepare-se, esta pergunta provavelmente parecerá ingênua e / ou tola, visto que eu sou relativamente novo no funcionamento interno de sistemas semelhantes a unix e programação em geral.

Pronto? Está bem! Eu vou passar por cerca de 3 níveis de ludicidade, aumentando à medida que vou adiante.

Nós temos dois sistemas com hardware similar (o ponto principal é o processador, digamos um intel core 2 duo padrão).

Um está rodando (insira sua distro linux aqui: o Ubuntu será usado daqui em diante), e o outro está rodando digamos o Mac OS X.

Um compila um programa equivalente, digamos algo como:

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

O código é extremamente simples, porque eu não quero considerar as implicações das bibliotecas compartilhadas ainda.

Quando compilado nos respectivos sistemas. Não é a principal diferença entre a saída de uma questão de ELF vs Mach-O? Se alguém tirasse cada binário da formatação, deixando um binário plano, as instruções da máquina desmontadas não seriam as mesmas? (com talvez algumas diferenças dependendo dos hábitos / tendências dos compiladores).

1.) Se alguém fosse desenvolver um programa para reempacotar o binário plano produzido em nosso sistema Ubuntu, na formatação Mach-O, ele seria executado no sistema Mac OS X? Então, se alguém tivesse apenas o binário compilado do programa acima, e alguém tivesse essa ferramenta mística para reempacotar binários planos, programas simples seriam capazes de rodar no sistema Mac OS X?

Agora vamos dar um passo adiante.

Agora temos um programa com fonte, como:

#include <stdio.h>
int main()
{
    printf("I like tortoises, but not porpoises");
    return 0;
}

2.) Supondo que este programa seja compilado e estaticamente ligado, nosso programa mágico ainda seria capaz de reempacotar o binário bruto no formato Mach-O e fazê-lo funcionar no Mac OS X? Visto que não precisaria depender de nenhum outro binário (para o qual o sistema mac não teria neste caso)

E agora para o nível final;

3.) E se usássemos este suposto programa para converter todas as bibliotecas compartilhadas necessárias para o formato Mach-O, e então compilássemos o programa acima com links dinâmicos. O programa ainda teria sucesso?

Deve ser por enquanto, obviamente, cada passo do absurdo depende da base anterior, até para fazer sentido. Então, se o primeiro pilar for destruído, duvido que haja muito mérito para os demais.

Eu definitivamente não iria tão longe a ponto de pensar nisso com programas com GUI em mente. Os sistemas de janelas provavelmente seriam uma outra dor de cabeça. Estou considerando apenas programas de linha de comando neste estágio.

Agora, eu convido o mundo para me corrigir, e me diga tudo que está errado com minha linha de pensamento absurda.

    
por zec 22.02.2011 / 22:54

5 respostas

24

Você se esquece de uma coisa crucial, a saber, que seu programa terá que interagir com o sistema operacional para fazer qualquer coisa interessante.

As convenções são diferentes entre o Linux e o OS X, portanto, o mesmo binário não pode ser executado como está, sem essencialmente ter um pedaço de código dependente do sistema operacional para poder interagir com ele. Muitas dessas coisas estão escondidas em bibliotecas, que você precisa vincular, e isso significa que seu programa precisa ser vinculável, e a vinculação também é diferente entre os dois sistemas.

E assim continua e continua. O que na superfície parece fazer a mesma coisa é muito diferente nos detalhes reais.

    
por 22.02.2011 / 23:02
15

Isso é factível se alguém quiser gastar tempo suficiente para que isso aconteça. O Projeto Darling está tentando fazer isso, embora no momento em que este texto foi escrito, está em um estado bastante primitivo.

Isso foi feito com sucesso antes em outras plataformas:

  • O Solaris e o UnixWare incluem um programa auxiliar chamado lxrun que funciona como sudo : você passa o nome e os parâmetros do executável para o auxiliar e conserta as coisas dinamicamente para que o executável possa falar com o sistema operacional. O site oficial (abaixo, archive link ) diz que é bitrotted .

  • O kernel do Linux já teve um recurso chamado iBCS que fez o contrário, exceto que não precisava um ajudante porque o kernel reconheceu os binários "estrangeiros" diretamente. caiu em desuso durante a série de desenvolvimento do kernel 2.3 , provavelmente porque a pequena batalha de servidores Unix foi essencialmente mais de uma vez 2.4 saiu.

  • O kernel do FreeBSD pode ser configurado para reconhecer os binários do Linux e executá-los como se fossem eram nativos. Esse recurso parece estar em melhor forma do que os dois acima.

    O OpenBSD e o NetBSD possuem recursos similares.

O OS X tem muito do FreeBSD nele , portar seu suporte para Linux pode ser simples.

    
por 23.02.2011 / 03:06
2

Concordo muito bem com todos, mas quero acrescentar que, embora isso demandasse uma quantidade significativa de tempo e esforço, não seria quase o mesmo que o necessário para desenvolver o Wine.

Muito do difícil no desenvolvimento do Wine é que eles estão portando um formato binário a partir de um sistema operacional de código fechado e muitas das chamadas do sistema não estão documentadas. Eles tiveram que essencialmente fazer engenharia reversa no sistema operacional.

Se alguém fizesse isso de um sistema operacional aberto para outro sistema operacional aberto, eles provavelmente conseguiriam fazê-lo em 1/10 do tempo, já que a camada de compatibilidade poderia ser copiada / colada do outro sistema operacional se um equivalente chamada de sistema nativo não existe. É claro que, na maioria dos casos, no mundo POSIX, haverá uma chamada nativa disponível.

Outro projeto de destaque é o ReactOS, onde eles estão essencialmente criando uma versão completa e compatível com o binário do Windows ... não há necessidade do Wine.

    
por 02.09.2014 / 06:23
0

Existem vários aplicativos especializados em Linux para os quais isso seria uma grande ajuda. No lado da FPGA, Quartus e Vivado são bons exemplos de programas que rodam sob o Linux e é improvável que haja código-fonte disponível para eles ou programas similares que visem os FPGAs mais recentes.

Acho que a resposta simples à sua pergunta é: recompilar no MacOS, onde você tem a fonte e formar um grupo para fornecer a capacidade se você tiver tempo - e isso será uma tarefa demorada.

    
por 04.08.2014 / 18:06
0

É tecnicamente factível em macOS, mas não sem esforço significativo, embora alguns dos esforços já tenham sido feitos para nós.

  • O macOS e o Red Hat Enterprise Linux renomeado foram certificados como UNIX 03. Isso significa que, em princípio, as chamadas POSIX devem ter a mesma API.
  • O macOS e o Linux usam o System V ABI para a plataforma amd64. Isso significa que, para o amd64, o macOS e o Linux devem ter ABI e API compatíveis.
  • O macOS usa o Mach-O como seu formato executável nativo enquanto o Linux usa o ELF. Isso facilita as coisas, pois o formato do arquivo executável pode ser usado para distinguir se a camada de compatibilidade deve ser chamada. Isso exigiria algo como binfmt_misc embora.
  • Existe uma extensão de kernel macOS de terceiros que fornece exatamente isso. Agora, temos uma maneira de carregar o macOS para carregar o ELF, precisamos do nosso ld-linux.so especial, que é um executável do Mach-O que carregaria nosso ELF e o executaria.

Agora, o que precisamos é de pelo menos um ld-linux.so especial que possa fazer o seguinte:

  • Seja um executável do Mach-O ou dyld ,
  • Pode carregar arquivos ELF do Linux na memória no endereço correto,
  • Esperamos poder mapear o soname do Linux para os macOS (exemplo /lib/libc.so.6 to /lib/libSystem.B.dylib ) e carregar o Mach-O correspondente quando um ELF correspondente não for encontrado, para que possamos reutilizar as bibliotecas do macOS

Com apenas aquele carregador acima do ELF que não faz syscalls diretos tem uma boa chance de funcionar, mas o ELF com syscalls pode não funcionar. Um segundo componente que pode ser útil seria uma extensão do kernel que captura os syscalls do Linux e os mapeia para os macOS. A partir dos usos da área de trabalho, é necessária uma implementação especial do plano para mapear as chamadas gráficas do Linux para OpenGL.framework e Metal.framework .

    
por 13.10.2018 / 15:39