Чи можливо використовувати компілятор Intel C / C ++ в Linux для створення об’єктних файлів для підключення до Windows?

Чому?

Залежно від вашого джерела, компілятор Intel, швидше за все, або, безумовно, компілятор, генеруючи найшвидші виконавчі файли для архітектури x86 (від 5 до 100% покращення часу виконання).

Intel пропонує свої компілятори для Linux за некомерційною ліцензією безкоштовно (я думаю, я читаю, що це безкоштовно десь на їхній сторінці: Intel - некомерційна розробка програмного забезпечення ). Існує також безкоштовна некомерційна ліцензія для студентів, але ця ліцензія не застосовується, хоча інструменти пропонуються для всіх трьох основних операційних систем (посилання відхилено через обмеження репутації).

Мета

Я (як не студент) хотів би мати можливість використовувати компілятори Intel для можливих поліпшень швидкості виконання згідно некомерційної ліцензії для компіляції об’єктних файлів, які можна пов’язати для створення виконавчих файлів та бібліотек динамічних посилань для Windows (і, можливо, ОС X)

Детальніше:

З цього документа я зробив висновок , що компілятори Intel створюють об’єктивні файли, сумісні з домінуючими компіляторами платформи.

Підпитання:

1. Які формати файлів об'єктних файлів gcc, g ++, cl, mingw32, icc, icpc та icl для Windows та Linux (поточні версії)?
2. Чи можуть бути використані частини ланцюжка інструментів крос-компілятора mingw32 для досягнення мети?
3. Я правий, що метадані в створених файлах об'єктів є основною проблемою?

ad 2:
схоже, що mingw32-objcopy може перетворити вихід компілятора Intel на Linux (імовірно, ELF) у сумісний з Microsoft COFF (за винятком можливого виключення об'єктів, що переміщуються). Чи може хтось підтвердити, що це насправді працює (для нетривіальних додатків)?

Можна створити виконувані файли Windows на машині збирання Linux за допомогою крос-компілятора. Але Intel не надає таких крос-компіляторів.

Щоб відповісти на підзапитання:

Які формати файлів об'єктних файлів gcc, g ++, cl, mingw32, icc, icpc та icl для Windows та Linux (поточні версії)?

Формат файлів об'єктів ефективно визначається операційною системою (точніше, компілятором, який використовується для його побудови). Для Windows це формат Portable Executable (PE) , а для Linux формат ELF .

Чи можуть бути використані частини ланцюжка інструментів крос-компілятора mingw32 для досягнення мети?

Ні. Відповідною частиною є генератор коду, який є як частиною, відповідальною за генерування правильного формату об'єкта, так і частиною компіляторів Intel, яка надає їхньому згенерованому коду швидкість межі.

Я правий, що метадані в створених файлах об'єктів є основною проблемою?

Ні. Це одне питання, але їх більше. Більш фундаментальною проблемою є різниця потенціалів у тому, як параметри передаються до ядра та / або стандартної бібліотеки. IIRC, ці конвенції відрізняються між Windows та Linux.

Відповідь майже напевно - так. Я знаю, що крос-компіляція бінарних файлів Windows (через mingw32 ) на вікні Linux легко можлива за допомогою gcc - очевидно, ви не зможете запустити програму в Linux (якщо вона не працює під Wine), але я знаю кілька програм, які отримують Таким чином, двійкові файли Windows.

Однак я не знаю, чи є у компілятора Intel варіанти для цього, я думаю, це так і є.

Формат об'єкта для Windows - це PE , тоді як для Linux - його ELF .

Якщо C-код посилається ні на що (безпосередньо), що використовує спеціальні конвенції Microsoft про виклики, ви можете мати шанс використовувати MinGW objcopy. Я використовував його для перетворення зібраного об'єктного файлу, але тоді мені не довелося переживати про виклик конвенцій.

Я б просто витратити час, який ви намагаєтеся зробити це, а не отримати GCC або кланг зробити саме те, що ви хочете. Якщо таке прискорення дійсно важливо, скомпілюйте бінарний файл Linux із компілятором Intel і спробуйте переконатися, що саме, якщо взагалі що-небудь, прискорює ваш код. Ви можете зафіксувати збірку, якщо все інше не вдасться.

Я пропоную наступну відповідь:

Певне, можливо, (схиляючись до так), але щодо контексту.

Пояснення: Що стосується "нахиленої" частини: Схоже, це не є марною тратою часу на спробу цього, але ("покласти" частину), враховуючи цю відповідь, ви, швидше за все, не отримаєте покращення часу виконання порівняно з Intel -тільки інструментальний ланцюг. Відповідна частина - це зворотний зв'язок між компілятором та ланцюгом часу виконання (оптимізація всієї програми, оптимізація за допомогою профілю, генерація коду посилання-час).

Додаткова деталь:
Відповідно до поширених запитань MinGW , можливі проблеми з використанням бібліотек та DLL:
"Хоча DLL повинні бути досить портативними для різних компіляторів Windows, доступ до dll через файл бібліотеки (.lib або .a) не є. Бібліотека формати файлів є специфічними для конкретних компіляторів, і їх не можна використовувати портативно з різними компіляторами, якщо компілятор не підтримує його. "

Щоб заповнити відповідь:
під питання 1:

Які формати файлів об'єктних файлів gcc, g ++, cl, mingw32, icc, icpc та icl для Windows та Linux (поточні версії)?

Формат файлу об'єкта за замовчуванням для будь-якого компілятора в Windows - це COFF (ймовірно, варіант PE ). Типовим форматом об'єктного файлу для будь-якого компілятора в Linux є ELF

під питання 2:

Чи можуть бути використані частини ланцюжка інструментів крос-компілятора mingw32 для досягнення мети?

Швидше за все, так (для посилальної частини), але, швидше за все, ви не отримаєте багато вдосконалення часу виконання.

під питання 3:

Я правий, що метадані в створених файлах об'єктів є основною проблемою?

Щодо зв’язування: так.