Por que os compiladores geralmente geram apenas executáveis ​​para a plataforma em que estão instalados?

Sou desenvolvedor C ++ e, na tentativa de entender melhor o desenvolvimento de plataforma cruzada, estou tentando entender melhor alguns detalhes de implementação dos compiladores e como exatamente eles criam binários específicos do SO. No meio do meu estudo, percebi que, pelo menos por um tempo, a maioria dos compiladores que você baixava para uma plataforma específica apenas compilava binários para essa plataforma. Portanto, se você baixou um IDE que acompanha um exe do compilador para Windows, esse compilador só poderá compilar seu programa para aplicativos do Windows x86-x64 e não para aplicativos Linux ou Mac.

Agora eu entendo que plataformas diferentes exigem formatos binários diferentes, mas o que dificulta dizer o compilador visual C ++ no Windows para gerar um arquivo executável binário linux? Contanto que você tenha as instruções de montagem para a CPU em que está sendo executado, bem como as bibliotecas específicas do SO, não será possível compilar produtos executáveis ​​para qualquer plataforma em qualquer máquina?

o que dificulta, digamos, o compilador visual C ++ no Windows gerar um arquivo executável binário linux?

Além de uma falta de vontade de fazer isso por parte da Microsoft, absolutamente nada. Os obstáculos não são técnicos.

As cadeias de ferramentas de desenvolvimento são apenas programas que recebem informações e produzem resultados. O Visual C ++ produz um assembly x86 e, em seguida, usa um assembler para convertê-lo em um arquivo de objeto COFF. Se a Microsoft quisesse gerar ELF, é apenas código: a montagem entra, a ELF sai. Não há nada mágico em arquivos ou bibliotecas de objetos; são apenas bolhas de dados em um formato bem compreendido.

No começo da era da pedra, a compilação cruzada era muito mais difícil porque, na maioria das vezes, você escrevia a cadeia de ferramentas para sua plataforma de destino na montagem da plataforma em que seria executada. Isso significava que, se tudo o que havia no mundo fossem as arquiteturas VAX, M68K e Alpha, um conjunto completo de compiladores cruzados exigiria a criação de nove deles, a maioria do zero. (VAX para VAX, VAX para M68K, VAX para Alpha, M68K para VAX, M68K para M68K etc.) Isso é um exagero, pois partes do compilador VAX podem ser reutilizadas e anexado aos geradores de código para cada destino (por exemplo, VAX, M68K e Alpha, cada um escrito para o VAX.)

Esse problema desapareceu quando começamos a escrever compiladores em um idioma que não estava vinculado a um processador específico, como um C. Seguir essa rota significa que você escreve toda a cadeia de ferramentas uma vez em C e usa uma plataforma escrita para a local Compilador C para construí-lo. (Você costuma usar o compilador para se recompilar após ter sido inicializado no compilador da plataforma local, mas isso é outra discussão.) O resultado disso é que a criação de um compilador cruzado se tornou essencialmente o mesmo esforço que a compilação de um compilador nativo no a plataforma local. A única diferença significativa é que, em algum ponto do processo de compilação, você pediu para compilar no gerador de código para sua plataforma de destino, em vez daquele na plataforma local, que seria a escolha lógica.

À medida que a arquitetura dos compiladores evoluiu, tornou-se conveniente incluir e construir todos os geradores de código com o produto e selecionar qual deles seria usado em tempo de execução. Clang / LLVM faz isso, e tenho certeza que existem outros.

Depois de ter uma cadeia de ferramentas de trabalho (compilador, montador, vinculador), as bibliotecas são construídas a partir de fontes e, eventualmente, você acaba com tudo o que precisa para produzir um arquivo executável para outra plataforma.

Sim, se você tiver todas as informações sobre sua plataforma de destino, não importa em qual plataforma você está realmente executando.

Existem dois problemas que tendem a surgir:

1. As pessoas não focam nisso porque é um cenário menos comum. Freqüentemente, a única coisa que você cruza a compilação é um compilador, para que você possa parar a compilação cruzada. Menos foco significa pior suporte.
2. Programas não triviais precisam de mais do que apenas código. Lidar com a inclusão / vinculação de bibliotecas fica um pouco mais fácil quando você tem bibliotecas para a plataforma em que está executando. Eles estarão em um local conhecido, em uma codificação conhecida.

Aqueles não são intransponíveis, é claro. Principalmente, você obtém compiladores direcionados à plataforma em que executam, porque é isso que as pessoas desejam.

Eu discordo de sua premissa. Existem milhões de desenvolvedores de Android e iOS. E todos eles usam compiladores executados no Windows ou em um Mac, produzindo código para um computador totalmente diferente.

Você não terá um compilador cruzado se não houver demanda de mercado por ele. As pessoas que desenvolvem código para uma área de trabalho Linux, por exemplo, geralmente têm uma área de trabalho Linux disponível e usam um compilador baseado em Linux - muito mais rápido se você puder executar seu aplicativo diretamente na máquina em que é compilado sem transportá-lo pela rede, muito mais fácil e rápido ter um depurador em execução na mesma máquina e assim por diante.

Então, quanto mais a Microsoft ganharia se seus compiladores também construíssem para Linux? Aproximadamente $ 0. Quanto mais software para Windows seria criado? Nenhum. Quanto mais software Linux seria criado? Não faço ideia, mas não é algo que a Microsoft se importe. Qual seria o custo? Consideravelmente. Os compiladores devem estar livres de erros. Eles devem ser testados.

Outro problema: se você escreve um compilador no Windows, precisa de alguém que saiba escrever o software do Windows. Se você escreve um compilador para Linux, precisa de alguém que saiba escrever software Linux. Se você escreve um compilador para Linux em execução no Windows, de repente precisa do pão muito mais raro de desenvolvedor que conhece o Windows e o Linux.