Est-il possible d'utiliser le compilateur Intel C / C ++ sous Linux pour créer des fichiers objets à lier sous Windows?

12

Pourquoi?

Selon votre source, le compilateur Intel est probablement ou très certainement le compilateur générant les exécutables les plus rapides pour l'architecture x86 (amélioration de 5 à 100% du temps d'exécution).

Intel propose gratuitement ses compilateurs pour Linux sous une licence non commerciale (je pense que je l'ai lu quelque part gratuitement sur leur page: Intel - Développement de logiciels non commerciaux ). Il existe également une licence non commerciale gratuite pour les étudiants, mais cette licence n'est pas applicable bien que des outils soient proposés pour les trois principaux systèmes d'exploitation (lien supprimé en raison d'une restriction de réputation).

Objectif

Je (en tant que non-étudiant) souhaite pouvoir utiliser les compilateurs Intel pour d'éventuelles améliorations de la vitesse d'exécution sous la licence non commerciale pour compiler des fichiers objets qui peuvent être liés pour créer des exécutables et des bibliothèques de liens dynamiques pour Windows (et éventuellement OS) X)

Plus de détails:

Ce que j'ai déduit de ce document, c'est que les compilateurs Intel créent des fichiers objets compatibles avec les compilateurs dominants de la plateforme.

Sous-questions:

Quels sont les formats de fichiers objets de gcc, g ++, cl, mingw32, icc, icpc et icl sous Windows et Linux (versions actuelles)?
Des parties de la chaîne d'outils du compilateur croisé mingw32 pourraient-elles être utilisées pour atteindre l'objectif?
Ai-je raison de dire que les métadonnées dans les fichiers objets générés sont le principal problème?

annonce 2:
mingw32-objcopy semble être capable de convertir la sortie du compilateur Intel sous Linux (vraisemblablement ELF) en COFF compatible avec Microsoft (à l'exception peut-être des fichiers objets relocalisables). Quelqu'un pourrait-il confirmer que cela fonctionne réellement (pour les applications non triviales), s'il vous plaît?

— Hugo
source

1

+1. Question interessante.

— Neil

Avez-vous regardé le vin? AFAIK, Wine fournit une chaîne d'outils qui peut créer des exécutables Windows sur Linux; vous pourriez peut-être y connecter icc. Vous pouvez également réussir à exécuter un icc Windows dans Wine et à le connecter avec une chaîne d'outils de compilation croisée ming32. Je ne l'ai pas essayé, mais avec suffisamment de violon, je pense que cela devrait être possible.

— tdammers

@tdammers Selon WineHQ, la chaîne d'outils pour construire des exécutables Windows sur Linux est mingw32, si je ne me trompe pas.

— Hugo

Sur les forums Intel, la réponse semble être "non": software.intel.com/en-us/forums/topic/282588

— Vitor Py

@VitorBraga J'ai interprété la question comme suit: "Le compilateur Intel est-il capable de compiler directement?" La réponse est "non" (pour autant que je sache, il manque les options et les bibliothèques requises), mais ... l'architecture informatique (IA32, AMD64) serait la même dans mon cas et si j'utilise uniquement des bibliothèques Windows pour compiler le programme sous Linux, je m'attendrais à obtenir du code exécutable qui pourrait être exécuté sous Windows - s'il est lié aux bibliothèques Windows pour créer un exécutable Windows.

— Hugo

1

Il est possible de créer des exécutables Windows sur une machine de génération Linux en utilisant un compilateur croisé. Mais Intel ne fournit pas de tels compilateurs croisés.

Pour répondre aux sous-questions:

Quels sont les formats de fichiers objets de gcc, g ++, cl, mingw32, icc, icpc et icl sous Windows et Linux (versions actuelles)?

Le format des fichiers objets est effectivement déterminé par le système d'exploitation (ou plutôt, le compilateur utilisé pour le construire). Pour Windows, c'est le format Portable Executable (PE) et pour Linux le format ELF .

Des parties de la chaîne d'outils du compilateur croisé mingw32 pourraient-elles être utilisées pour atteindre l'objectif?

Non. La partie pertinente est le générateur de code, qui est à la fois la partie responsable de la génération du bon format d'objet et la partie sur les compilateurs Intel qui donne à leur code généré l'avantage.

Ai-je raison de dire que les métadonnées dans les fichiers objets générés sont le principal problème?

Non. C'est un problème, mais il y en a plus. Un problème plus fondamental est la différence potentielle dans la façon dont les paramètres sont transmis au noyau et / ou à la bibliothèque standard. IIRC, ces conventions sont différentes entre Windows et Linux.

— Bart van Ingen Schenau
source

0

La réponse est presque certainement oui. Je sais que la compilation croisée de binaires Windows (via mingw32 ) sur une boîte Linux est facilement possible en utilisant gcc - évidemment vous ne pourrez pas exécuter le programme sous Linux (à moins que cela fonctionne sous Wine), mais je connais plusieurs programmes qui obtiennent Les binaires Windows de cette façon.

Cependant, je ne sais pas si le compilateur Intel a les options pour cela, je pense que oui.

Le format d'objet pour Windows est PE , tandis que pour Linux son ELF .

— gbjbaanb
source

Selon msdn : "Les compilateurs produisent des fichiers d'objet COFF (Common Object File Format)." <br/>

— Hugo

OK, cela n'a pas fonctionné. Selon Wikipedia, PE est dérivé de COFF et les deux formats de fichier peuvent être utilisés comme format de fichier objet et format de fichier exécutable.

— Hugo

0

Avec le code C lié à rien (directement) qui utilise les conventions d'appel personnalisées de Microsoft, vous pourriez avoir une chance d'utiliser MinGW objcopy. Je l'ai utilisé pour convertir un fichier objet assemblé, mais je n'ai pas eu à me soucier d'appeler les conventions.

Je passerais juste le temps que vous essayez de faire à la place pour que GCC ou clang fasse exactement ce que vous voulez. Si une telle accélération est vraiment si importante, compilez un binaire Linux avec le compilateur Intel et essayez de voir exactement ce qui, le cas échéant, accélère votre code. Vous pouvez patcher l'assembly si tout le reste échoue.

— Ericson2314
source

0

Je propose la réponse suivante:

Un définitif peut-être (penché vers oui) avec un mais en ce qui concerne le contexte.

Explication: Concernant la partie "penchée": Il ne semble pas être une perte de temps totale d'essayer, mais (la partie "mettre") compte tenu de cette réponse, vous n'obtiendrez probablement pas les améliorations du temps d'exécution par rapport à un Intel -chaîne d'outils uniquement. La partie pertinente étant l'éditeur de liens et le retour d'exécution au compilateur (optimisation complète du programme, optimisation guidée par le profil, génération de code de temps de liaison).

Détail supplémentaire:
selon la FAQ MinGW, l' utilisation de bibliothèques et de DLL peut poser des problèmes:
"Bien que les DLL soient censées être assez portables sur différents compilateurs Windows, l'accès aux DLL via un fichier de bibliothèque (.lib ou .a) ne l'est pas. La bibliothèque les formats de fichiers sont spécifiques à des compilateurs particuliers et ne peuvent pas être utilisés de manière portable avec différents compilateurs à moins que le compilateur ne les prenne en charge. "

Pour compléter la réponse:
sous-question 1:

Quels sont les formats de fichiers objets de gcc, g ++, cl, mingw32, icc, icpc et icl sous Windows et Linux (versions actuelles)?

Le format de fichier objet par défaut pour tout compilateur sous Windows est COFF (probablement la variante PE ). Le format de fichier objet par défaut pour tout compilateur sous Linux est ELF

sous-question 2:

Des parties de la chaîne d'outils du compilateur croisé mingw32 pourraient-elles être utilisées pour atteindre l'objectif?

Très probablement oui (pour la partie de liaison), mais très probablement vous n'obtiendrez pas beaucoup d'amélioration du temps d'exécution.

sous-question 3:

Ai-je raison de dire que les métadonnées dans les fichiers objets générés sont le principal problème?

Concernant la liaison: oui.

— Hugo
source