Можно ли использовать компилятор Intel C / C ++ в Linux для создания объектных файлов, которые будут связаны в Windows?

Почему?

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

Intel бесплатно предлагает свои компиляторы для Linux по некоммерческой лицензии (думаю, я читал, что это бесплатно где-то на их странице: Intel - Разработка некоммерческого программного обеспечения ). Существует также бесплатная некоммерческая лицензия для студентов, но эта лицензия не применима, хотя инструменты предлагаются для всех трех основных операционных систем (ссылка потеряна из-за ограничения репутации).

Цель

Я (не студент) хотел бы иметь возможность использовать компиляторы Intel для возможных улучшений скорости выполнения в рамках некоммерческой лицензии для компиляции объектных файлов, которые могут быть связаны для создания исполняемых файлов и динамических библиотек для Windows (и, возможно, ОС ИКС)

Больше деталей:

Из этого документа я сделал вывод, что компиляторы Intel создают объектные файлы, совместимые с доминирующими компиляторами платформы.

Суб-вопросы:

1. Каковы форматы объектных файлов gcc, g ++, cl, mingw32, icc, icpc и icl в Windows и Linux (текущие версии)?
2. Могут ли части кросс-компилятора mingw32 использоваться для достижения цели?
3. Прав ли я, что метаданные в сгенерированных объектных файлах являются основной проблемой?

Объявление 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 или Clang делать именно то, что вы хотите. Если такое ускорение действительно так важно, скомпилируйте двоичный файл Linux с помощью компилятора Intel и постарайтесь точно определить, что, если вообще что-то происходит, ускоряет ваш код. Вы можете патчить сборку, если ничего не помогает.

Я предлагаю следующий ответ:

Определенное может быть (склоняется к да), но с учетом контекста.

Объяснение: Что касается «наклоняющейся» части: похоже, это не пустая трата времени, чтобы попробовать это, но (часть «положить»), принимая во внимание этот ответ, вы, скорее всего, не получите улучшения времени выполнения по сравнению с Intel -только цепочка инструментов. Соответствующая часть - это компоновщик и обратная связь времени выполнения с компилятором (оптимизация всей программы, оптимизация на основе профиля, генерация кода во время компоновки).

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

Чтобы завершить ответ:
подвопрос 1:

Каковы форматы объектных файлов gcc, g ++, cl, mingw32, icc, icpc и icl в Windows и Linux (текущие версии)?

Формат файла объекта по умолчанию для любого компилятора в Windows - COFF (вероятно, вариант PE ). Формат файла объекта по умолчанию для любого компилятора в Linux - ELF

подвопрос 2:

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

Скорее всего, да (для связующей части), но, скорее всего, вы не получите большого улучшения времени выполнения.

подвопрос 3:

Прав ли я, что метаданные в сгенерированных объектных файлах являются основной проблемой?

По поводу ссылок: да.