Pourquoi les compilateurs ne génèrent généralement que des exécutables pour la plate-forme sur laquelle ils sont installés?


10

Je suis un développeur C ++ et dans une tentative de mieux comprendre le développement multiplateforme, j'essaie de mieux comprendre certains détails d'implémentation des compilateurs et comment exactement ils créent des binaires spécifiques au système d'exploitation. Au milieu de mon étude, j'ai réalisé que, au moins pendant un certain temps, la plupart des compilateurs que vous avez téléchargés pour une plate-forme spécifique n'ont compilé que des binaires pour cette plate-forme. Donc, si vous avez téléchargé un IDE fourni avec un compilateur exe pour Windows, ce compilateur ne pourra compiler votre programme que pour les applications Windows x86-x64 et non pour les applications Linux ou Mac.

Maintenant, je comprends que différentes plates-formes nécessitent différents formats binaires, mais qu'est-ce qui rend difficile, par exemple, le compilateur C ++ visuel sous Windows pour générer un fichier exécutable binaire linux? Tant que vous avez les instructions d'assemblage pour le processeur sur lequel vous travaillez, ainsi que les bibliothèques spécifiques au système d'exploitation, ne devriez-vous pas être en mesure de compiler des exécutables pour n'importe quelle plate-forme sur n'importe quelle machine?


5
Il existe de nombreux compilateurs croisés: je ne sais pas pourquoi vous pensez que la compilation croisée est rare. Visual C ++ est logique étant donné que Microsoft souhaite le verrouillage de Windows, mais ils fournissent même des outils de compilation Android dans VS2017.

Eh bien, beaucoup d'autres sites semblaient se révéler comme un compilateur de compilation croisée est très difficile à implémenter et ce n'est que récemment que plus de compilateurs multiplateformes ont vu le jour. Si cela est vrai, je me demande simplement ce qui rendrait la compilation croisée difficile si vous n'avez besoin que de certaines instructions d'assemblage du processeur et des appels de systèmes natifs pour le système d'exploitation correspondant
Jason

Je pense que vous avez ici un problème de compréhension de la terminologie qui peut prêter à confusion. Vous utilisez de manière interchangeable le "compilateur croisé" et le "compilateur multiplateforme", mais ce sont des choses différentes (bien que liées): un compilateur croisé est un compilateur pour une plate-forme différente de celle que vous utilisez, et ces choses sont disponibles depuis aussi longtemps que les compilateurs. Un compilateur multiplateforme est un compilateur qui utilise une étape intermédiaire pour séparer le traitement et l'optimisation du langage source de la génération de code spécifique à la plate-forme afin qu'il puisse être utilisé. ..
Jules

... pour la compilation de code pour plusieurs plates-formes cibles avec un minimum de changements. Ces choses sont une innovation plus récente et beaucoup plus complexe.
Jules

Réponses:


18

qu'est-ce qui rend difficile pour le compilateur visuel C ++ sous Windows de générer un fichier exécutable binaire linux?

À part une réticence à le faire de la part de Microsoft, absolument rien. Les obstacles ne sont pas techniques.

Les chaînes d'outils de développement ne sont que des programmes qui prennent des entrées et produisent des sorties. Visual C ++ produit un assemblage x86, puis utilise un assembleur pour le convertir en un fichier objet COFF. Si Microsoft voulait plutôt le faire générer ELF, c'est juste du code: l'assemblage entre, ELF s'éteint. Il n'y a rien de magique dans les fichiers objets ou les bibliothèques; ce ne sont que des taches de données dans un format bien compris.

À l'époque de la pierre, la compilation croisée était beaucoup plus difficile car, le plus souvent, vous auriez écrit la chaîne d'outils de votre plate-forme cible en l'assemblant pour la plate-forme où elle s'exécuterait. Cela signifiait que si tout ce qu'il y avait dans le monde était les architectures VAX, M68K et Alpha, une suite complète de compilateurs croisés nécessiterait d'en écrire neuf, la plupart à partir de zéro. (VAX à VAX, VAX à M68K, VAX à Alpha, M68K à VAX, M68K à M68K, etc.) C'est un peu exagéré car certaines parties du compilateur VAX pourraient être réutilisées et attaché aux générateurs de code pour chaque cible (par exemple, VAX, M68K et Alpha, chacun écrit pour VAX.)

Ce problème a disparu lorsque nous avons commencé à écrire des compilateurs dans un langage qui n'était pas lié à un processeur spécifique, un tel C.Cette voie signifie que vous écrivez la chaîne d'outils entière une fois en C et utilisez une plate-forme écrite pour la plate-forme locale Compilateur C pour le construire. (Vous utiliseriez souvent le compilateur pour se recompiler après avoir été amorcé sur le compilateur de la plate-forme locale, mais c'est une autre discussion.) Le résultat est que la construction d'un compilateur croisé est devenue essentiellement le même effort que la construction d'un compilateur natif sur la plateforme locale. La seule différence significative est que quelque part dans le processus de construction, vous lui avez dit de compiler dans le générateur de code pour votre plate-forme cible au lieu de celui pour la plate-forme locale, ce qui aurait été le choix logique.

À mesure que l'architecture des compilateurs évoluait, il devenait pratique d'inclure et de construire simplement tous les générateurs de code avec le produit et de sélectionner celui qui sera utilisé au moment de l'exécution. Clang / LLVM fait cela, et je suis sûr qu'il y en a d'autres.

Une fois que vous avez une chaîne d'outils fonctionnelle (compilateur, assembleur, éditeur de liens), les bibliothèques sont construites à partir de sources et, finalement, vous vous retrouvez avec tout ce dont vous avez besoin pour produire un fichier exécutable pour une autre plate-forme.


C'est maintenant la meilleure réponse, la plus approfondie. Je pense que l'histoire aide vraiment à comprendre le contexte.
Jason

3
@Jason Parfois, il vaut mieux être vieux. :-)
Blrfl

4
"À part une réticence à le faire de la part de Microsoft, absolument rien." - Je n'appellerais pas cela "réticence". Microsoft est une entreprise à but lucratif cotée en bourse; ils ont certaines responsabilités envers leurs actionnaires et parties prenantes. Ils auraient besoin d'embaucher, de former et de payer des développeurs pour le backend Linux, ils auraient besoin d'embaucher, de former et de payer des testeurs pour le backend Linux, ils auraient besoin d'embaucher, de former et de payer du personnel de support familier avec le backend Linux, ils auraient besoin de concevoir, développer, maintenir, soutenir et étendre le code, le tout pour une plate-forme qui est…
Jörg W Mittag

… En dehors de leur cœur de métier. Et tout cela juste pour ajouter un n + 1ème compilateur aux n compilateurs déjà existants que vous pourriez tout aussi bien utiliser. Quel serait l' avantage commercial pour Microsoft de concurrencer GCC, Clang, ICC (Intel), xlc (IBM), Digital Mars, tcc, pcc, TenDRA, Metrowerks, PathScale,…? Personnellement, je ne pense pas qu'il y en ait.
Jörg W Mittag

3
@ JörgWMittag What would be the business benefit ... I don't think there is any.- Cela semble être une bonne raison de ne pas vouloir le faire.
Blrfl

8

Oui, si vous avez toutes les informations sur votre plate-forme cible, peu importe sur quelle plate-forme vous utilisez réellement.

Il y a deux problèmes qui ont tendance à surgir:

  1. Les gens ne s'y concentrent pas parce que c'est un scénario moins courant. Souvent, la seule chose que vous recoupez est un compilateur, vous pouvez donc arrêter la compilation croisée. Moins de concentration signifie moins de soutien.
  2. Les programmes non triviaux ont besoin de plus que du code. La gestion de l'inclusion / liaison de bibliothèques devient un peu plus facile lorsque vous disposez de bibliothèques pour la plate-forme sur laquelle vous travaillez. Ils seront dans un endroit bien connu, dans un encodage bien connu.

Ce ne sont bien sûr pas insurmontables. Généralement, vous obtenez des compilateurs qui ciblent la plate-forme sur laquelle ils s'exécutent, car c'est ce que les gens veulent.


Je vois. Merci pour la clarification. Cela a plus de sens pour moi maintenant.
Jason

Je le blâme sur intellisense.
JeffO

2

Je suis en désaccord avec votre prémisse. Il y a des millions de développeurs Android et iOS. Et ils utilisent tous des compilateurs fonctionnant sous Windows ou un Mac, produisant du code pour un ordinateur entièrement différent.

Vous n'obtiendrez pas de compilateur croisé s'il n'y a pas de demande sur le marché. Les personnes développant du code pour un bureau Linux, par exemple, ont généralement un bureau Linux disponible et utiliseront un compilateur basé sur Linux - beaucoup plus rapide si vous pouvez exécuter votre application directement sur la machine où elle est compilée sans la transporter sur le réseau, beaucoup plus facile et plus rapide d'avoir un débogueur en cours d'exécution sur la même machine et ainsi de suite.

Alors, combien d'argent gagnerait Microsoft si leurs compilateurs construisaient également pour Linux? Environ 0 $. Combien de logiciels supplémentaires pour Windows seraient créés? Aucun. Combien de logiciels Linux supplémentaires seraient créés? Aucune idée, mais ce n'est pas quelque chose dont Microsoft se soucie. Quel serait le coût? Assez considérablement. Les compilateurs doivent être exempts de bogues. Ils doivent être testés.

Un autre problème: si vous écrivez un compilateur écrivant sur Windows, vous avez besoin de quelqu'un qui sait écrire un logiciel Windows. Si vous écrivez un compilateur pour Linux, vous avez besoin de quelqu'un qui sait écrire un logiciel Linux. Si vous écrivez un compilateur pour Linux fonctionnant sous Windows, vous avez soudainement besoin du pain beaucoup plus rare de développeur qui connaît à la fois Windows et Linux.


"Il y a des millions de développeurs Android et iOS. Et ils utilisent tous des compilateurs fonctionnant sur Windows ou un Mac, produisant du code pour un ordinateur entièrement différent." Non, non. De nombreux développeurs Android utilisent Linux, et en fait c'est la plate-forme la plus populaire pour les développeurs selon la propre enquête de StackExchange.
Miles Rout
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.