¿Es posible usar el compilador Intel C / C ++ en Linux para crear archivos de objetos que se vincularán en Windows?

¿Por qué?

Dependiendo de su fuente, el compilador Intel es probable o definitivamente el compilador que genera los ejecutables más rápidos para la arquitectura x86 (mejora del tiempo de ejecución del 5 al 100%).

Intel ofrece sus compiladores para Linux bajo una licencia no comercial de forma gratuita (creo que he leído que es gratis en algún lugar de su página: Intel - Desarrollo de software no comercial ). También hay una licencia no comercial gratuita para los estudiantes, pero esta licencia no es aplicable, aunque se ofrecen herramientas para los tres principales sistemas operativos (enlace eliminado debido a la restricción de reputación).

Objetivo

A mí (como no estudiante) me gustaría poder usar los compiladores Intel para posibles mejoras en la velocidad de ejecución bajo la licencia no comercial para compilar archivos de objetos que se pueden vincular para crear ejecutables y bibliotecas de enlaces dinámicos para Windows (y posiblemente SO X)

Más detalles:

Lo que deduje de este documento es que los compiladores de Intel crean archivos de objetos que son compatibles con los compiladores dominantes de la plataforma.

Sub-preguntas:

1. ¿Cuáles son los formatos de archivo de objetos de gcc, g ++, cl, mingw32, icc, icpc e icl en Windows y Linux (versiones actuales)?
2. ¿Se podrían utilizar partes de la cadena de herramientas de compilación cruzada mingw32 para lograr el objetivo?
3. ¿Tengo razón en que los metadatos en los archivos de objetos generados son el problema principal?

anuncio 2:
mingw32-objcopy parece ser capaz de convertir la salida del compilador Intel en Linux (presumiblemente ELF) a COFF compatible con Microsoft (con la posible excepción de archivos de objetos reubicables). ¿Podría alguien confirmar que esto realmente funciona (para aplicaciones no triviales), por favor?

Es posible crear ejecutables de Windows en una máquina de compilación de Linux utilizando un compilador cruzado. Pero, Intel no proporciona tales compiladores cruzados.

Para responder las subpreguntas:

¿Cuáles son los formatos de archivo de objetos de gcc, g ++, cl, mingw32, icc, icpc e icl en Windows y Linux (versiones actuales)?

El formato de los archivos de objeto está determinado efectivamente por el sistema operativo (o más bien, el compilador utilizado para construirlo). Para Windows, este es el formato Portable Executable (PE) y para Linux el formato ELF .

¿Se podrían utilizar partes de la cadena de herramientas de compilación cruzada mingw32 para lograr el objetivo?

No. La parte relevante es el generador de código, que es la parte responsable de generar el formato de objeto correcto y la parte en los compiladores Intel que le da a su código generado la ventaja de velocidad.

¿Tengo razón en que los metadatos en los archivos de objetos generados son el problema principal?

No. Es un problema, pero hay más. Un problema más fundamental es la diferencia potencial en cómo se pasan los parámetros al kernel y / o la biblioteca estándar. IIRC, esas convenciones son diferentes entre Windows y Linux.

La respuesta es casi seguro que sí. Sé que la compilación cruzada de binarios de Windows (a través de mingw32 ) en una caja de Linux es fácilmente posible usando gcc; obviamente, no podrá ejecutar el programa en Linux (a menos que funcione en Wine), pero conozco varios programas que obtienen Windows binarios de esta manera.

Sin embargo, no sé si el compilador de Intel tiene las opciones para esto, creo que sí.

El formato de objeto para Windows es PE , mientras que para Linux es ELF .

Con el código C vinculado a la nada (directamente) que usa las convenciones de llamadas personalizadas de Microsoft, puede tener la posibilidad de usar MinGW objcopy. Lo he usado para convertir un archivo de objeto ensamblado, pero no tuve que preocuparme por llamar a convenciones.

Simplemente pasaría el tiempo que intentaría hacer esto en lugar de hacer que GCC o clang haga exactamente lo que quiere. Si tal aceleración es realmente tan importante, compile un binario de Linux con el compilador Intel e intente ver exactamente qué, si es que hay algo, acelera su código. Puede parchear el ensamblaje si todo lo demás falla.

Propongo la siguiente respuesta:

Un definitivo quizás (inclinado hacia sí) con un pero con respecto al contexto.

Explicación: Con respecto a la parte "inclinada": Parece que no es una pérdida total de tiempo intentar esto, pero (la parte "puesta") teniendo en cuenta esta respuesta, es probable que no obtenga las mejoras en el tiempo de ejecución en comparación con un Intel -solo cadena de herramientas. La parte relevante es el enlazador y la retroalimentación de tiempo de ejecución para el compilador (optimización de todo el programa, optimización guiada por perfil, generación de código de tiempo de enlace).

Detalles adicionales:
De acuerdo con las Preguntas frecuentes de MinGW, existen posibles problemas con el uso de bibliotecas y archivos DLL:
"Aunque se supone que los dlls son bastante portátiles en diferentes compiladores de Windows, no es posible acceder a los dlls a través de un archivo de biblioteca (.lib o .a). La biblioteca no lo es. los formatos de archivo son específicos de compiladores particulares y no se pueden usar de manera portátil con diferentes compiladores a menos que el compilador lo admita ".

Para completar la respuesta:
subpregunta 1:

¿Cuáles son los formatos de archivo de objetos de gcc, g ++, cl, mingw32, icc, icpc e icl en Windows y Linux (versiones actuales)?

El formato de archivo de objeto predeterminado para cualquier compilador en Windows es COFF (probablemente la variante PE ). El formato de archivo de objeto predeterminado para cualquier compilador en Linux es ELF

subpregunta 2:

¿Se podrían utilizar partes de la cadena de herramientas de compilación cruzada mingw32 para lograr el objetivo?

Lo más probable es que sí (para la parte de enlace), pero lo más probable es que no obtenga mucha mejora en el tiempo de ejecución.

subpregunta 3:

¿Tengo razón en que los metadatos en los archivos de objetos generados son el problema principal?

En cuanto a la vinculación: sí.