Perché i compilatori in genere generano solo eseguibili per la piattaforma su cui sono installati?

Sono uno sviluppatore C ++ e nel tentativo di comprendere meglio lo sviluppo multipiattaforma, sto cercando di comprendere meglio alcuni dettagli di implementazione dei compilatori e come esattamente creano binari specifici del sistema operativo. Nel mezzo del mio studio mi sono reso conto che, almeno per un po ', la maggior parte dei compilatori che hai scaricato per una piattaforma specifica ha compilato solo i binari per quella piattaforma. Quindi, se hai scaricato un IDE fornito con un exe di compilatore per Windows, quel compilatore sarebbe in grado di compilare il tuo programma solo per applicazioni Windows x86-x64 e non per applicazioni Linux o Mac.

Ora capisco che piattaforme diverse richiedono formati binari diversi, ma cosa rende difficile dire che il compilatore Visual C ++ su Windows generi un file eseguibile binario linux? Finché si hanno le istruzioni di assemblaggio per la CPU su cui si è in esecuzione, così come le librerie specifiche del sistema operativo, non si dovrebbe essere in grado di compilare file estraibili per qualsiasi piattaforma su qualsiasi macchina?

cosa rende difficile dire al compilatore Visual C ++ su Windows di generare un file eseguibile binario linux?

A parte la riluttanza a farlo da parte di Microsoft, assolutamente nulla. Gli ostacoli non sono tecnici.

Le toolchain di sviluppo sono solo programmi che accettano input e producono output. Visual C ++ produce un assembly x86 e quindi utilizza un assemblatore per convertirlo in un file oggetto COFF. Se Microsoft voleva invece generare ELF, è solo codice: entra l'assemblaggio, ELF esce. Non c'è nulla di magico nei file oggetto o nelle librerie; sono solo blocchi di dati in un formato ben compreso.

Nel lontano passato, la compilazione incrociata era molto più difficile perché il più delle volte avresti scritto la catena di strumenti per la tua piattaforma di destinazione in assemblaggio per la piattaforma in cui sarebbe stata eseguita. Ciò significava che se tutto ciò che c'era al mondo fossero le architetture VAX, M68K e Alpha, una suite completa di cross-compilatori avrebbe richiesto di scriverne nove, principalmente da zero. (VAX-to-VAX, VAX-to-M68K, VAX-to-Alpha, M68K-to-VAX, M68K-to-M68K, ecc.) È un po 'esagerato poiché parti del compilatore VAX potrebbero essere riutilizzate e collegato ai generatori di codice per ciascun target (ad esempio, VAX, M68K e Alpha, ciascuno scritto per VAX.)

Il problema è scomparso quando abbiamo iniziato a scrivere compilatori in una lingua che non era legata a un processore specifico, ad esempio C. Seguire questa strada significa scrivere l'intera toolchain una volta in C e utilizzare una piattaforma scritta per la piattaforma locale Compilatore C per costruirlo. (Utilizzerai spesso il compilatore per ricompilare se stesso dopo che è stato avviato il bootstiler sul compilatore della piattaforma locale, ma questa è un'altra discussione. Il risultato di questo è che costruire un cross-compilatore è diventato essenzialmente lo stesso sforzo di costruire un compilatore nativo su la piattaforma locale. L'unica differenza significativa è che da qualche parte nel processo di compilazione, hai detto di compilare il generatore di codice per la tua piattaforma di destinazione anziché quello per la piattaforma locale, che sarebbe stata la scelta logica.

Man mano che l'architettura dei compilatori si è evoluta, è diventato conveniente includere e creare semplicemente tutti i generatori di codice con il prodotto e selezionare quale viene utilizzato in fase di esecuzione. Clang / LLVM fa questo, e sono sicuro che ce ne sono altri.

Una volta che hai una toolchain funzionante (compilatore, assemblatore, linker), le librerie vengono costruite dai sorgenti e alla fine ottieni tutto il necessario per produrre un file eseguibile per qualche altra piattaforma.

Sì, se hai tutte le informazioni sulla tua piattaforma di destinazione, non dovrebbe importare su quale piattaforma stai effettivamente eseguendo.

Ci sono due problemi che tendono a spuntare:

1. Le persone non si concentrano su di esso perché è uno scenario meno comune. Spesso l'unica cosa che incrocia la compilazione è un compilatore, quindi puoi interrompere la compilazione incrociata. Meno attenzione significa peggio supporto.
2. I programmi non banali richiedono più di un semplice codice. Gestire l'inclusione / il collegamento delle librerie diventa un po 'più semplice quando si hanno librerie per la piattaforma su cui si sta eseguendo. Saranno in una posizione ben nota, in una codifica ben nota.

Ovviamente non sono insormontabili. Per lo più, ottieni compilatori che prendono di mira la piattaforma su cui girano perché è quello che la gente vuole.

Non sono d'accordo con la tua premessa. Ci sono milioni di sviluppatori Android e iOS. E tutti usano compilatori in esecuzione su Windows o Mac, producendo codice per un computer completamente diverso.

Non otterrai un compilatore incrociato se non è richiesta dal mercato. Le persone che sviluppano codice per un desktop Linux, ad esempio, hanno per lo più un desktop Linux disponibile e useranno un compilatore basato su Linux - molto più veloce se è possibile eseguire l'applicazione direttamente sul computer in cui è compilata senza trasportarla sulla rete, molto più facile e veloce avere un debugger in esecuzione sullo stesso computer e così via.

Quindi quanti soldi farebbero Microsoft se i loro compilatori costruissero anche per Linux? Circa $ 0. Quanto più software verrà creato per Windows? Nessuna. Quanto più software Linux verrebbe creato? Non ne ho idea, ma a Microsoft non importa qualcosa. Quale sarebbe il costo? Abbastanza considerevolmente. I compilatori devono essere privi di bug. Devono essere testati.

Un altro problema: se scrivi un compilatore che scrive su Windows, hai bisogno di qualcuno che sappia come scrivere il software Windows. Se scrivi un compilatore per Linux hai bisogno di qualcuno che sappia scrivere software Linux. Se scrivi un compilatore per Linux in esecuzione su Windows, improvvisamente hai bisogno del pane molto più raro dello sviluppatore che conosce sia Windows che Linux.