Кросс компиляция для windows

Кросс-компиляция Gwyddion для MS Windows под Linux весьма похожа на обычную сборку для Unix с некоторыми дополнительными настройками и дополнительными шагами. Хотя процесс достаточно тривиален, начальные настройки могут показаться в какой-то степени непростыми. Если вы к тому же не знакомы с обычной сборкой под Unix, имеет смысл начать с неё и попробовать кросс-компиляцию после того, как основная процедура станет понятной.

Эти инструкции описывают компиляцию в дистрибутиве Fedora используя дистрибутивную поддержку кросс-компиляции MinGW, поскольку разработчики Gwyddion используют именно этот вариант. В общем, эти инструкции работают в текущей версии Fedora. Компиляция в других версиях и других основанных на RedHat дистрибутивах (CentOS, Scientific Linux, …) будет происходить подобным образом и достаточно проста, но возможно потребуются некоторые небольшие изменения. Сборка, например, в openSUSE потребует модификации. Мы будем рады получить отчёты об успешной (или неудачной) сборке на других системах и дополнить эти инструкции.

Полная кросс-компиляция включает в себя следующие шаги:

• настройка для mingw64/mingw32,
• компиляция,
• установка во временный каталог
• создание программы установки используя NSIS.

Доступен скрипт, который автоматически проведёт все шаги, как описано ниже.

Настройка

Перед первой компиляцией может потребоваться настройка среды кросс-компиляции. Это надо делать только один раз.

Основные пакеты MinGW

Запустите с правами суперпользователя root:

dnf install mingw<32,64>—

чтобы установить необходимые пакеты mingw32 и mingw64. Некоторые другие пакеты будут установлены как зависимости пакетов, указанных здесь явно. Следует отметить, что технически некоторые из пакетов являются опциональными зависимостями и можно собрать пакет установки для MS Windows без них (после небольшой настройки). Тем не менее, стандартные пакеты установки включают эти зависимости, и скрипты кросс-компиляции подразумевают их наличие по умолчанию.

Репозиторий Gwyddion.net

Версии для MinGW некоторых пакетов, используемых Gwyddion, ещё (или уже) недоступны в Fedora, либо могут быть некоторые исправления, отсутсутствующие в пакетах Fedora, которые мы хотели бы включить. В настоящее время единственный недоступный пакет это gtksourceview2 который используется только в pygwy.

Можно собрать эти опциональные пакеты используя патчи и spec-файлы с http://sourceforge.net/projects/gwyddion/files/mingw32-cross-compile/, однако, гораздо проще установить их командой dnf . Для этого нужно загрузить и установить пакет конфигурации репозитория gwyddion.net. Его установка сделает доступными все дополнительные пакеты MinGW. После его установки можно запустить

dnf install mingw32-gtksourceview2

Кстати этот репозиторий также содержит родной пакет Gwyddion для архитектуры x86_64, который можно установить для использования Gwyddion c Fedora; и пакеты с кросс-компилированными библиотеками Gwyddion, которые можно использовать для кросс-компиляции модулей.

Wine является слоем совместимости/(не) эмулятором MS Windows для Unix. Он используется для запуска NSIS который создает программу установки Gwyddion для Windows. Wine также можно использовать для запуска и тестирования собранного кросс-компиляцией Gwyddion, как описано ниже.

dnf install wine

чтобы установить Wine.

Nullsoft scriptable install system (NSIS) используется для создания программы установки Gwyddion. Поскольку это программа для MS Windows, она устанавливается под Wine . Собранная кросс-компиляцией версия NSIS может присутствовать в некоторых дистрибутивах, но, как показала практика, оригинальная версия работает более надёжно.

Загрузите NSIS с его веб-страницы и запустите

заменяя 2.46 текущей версией. Версия NSIS 2.46 самая старая из протестированных.

Python

Чтобы собрать pygwy нужно установить Python в Wine. Это делается так же, как при обычной установке pygwy, за исключением того, что все пакеты, описанные в разделе включение pygwy необходимо устанавливать с помощью команды msiexec :

wine msiexec /i python-2.7.13.msi
wine msiexec /i pygobject-2.28.3.win32-py2.7.msi
wine msiexec /i pycairo-1.8.10.win32-py2.7.msi
wine msiexec /i pygtk-2.24.0.win32-py2.7.msi

или подобным образом.

Скрипты поддержки

Скрипты поддержки и данные доступны в модуле mingw32-cross-compile репозитория subversion программы Gwyddion. нужно запустить

svn checkout http://svn.code.sf.net/p/gwyddion/code/trunk/mingw32-cross-compile

чтобы получить снимок репозитория.

Наиболее важным из полученных вами является скрипт cross-build-32 (или cross-build-64 ), который автоматизирует все шаги кросс-компиляции. Перед тем, как запускать его в первый раз, просмотрите файл setup32 (или setup64 для 64-битных сборок), который определяет где находятся различные нужные вещи. По умолчанию его содержимое выглядит следующим образом:

Переменная source_dir задаёт место, куда был распакован архив или сохранён снимок системы контроля версий исходного кода Gwyddion и эту переменную скорей всего нужно будет изменить. Переменная target_prefix указывает каталог установки (временный каталог) для собранного кросс-компиляцией Gwyddion. Значение по умолчанию должно работать, и вам не нужно его менять, если вы этого не хотите. Оставшиеся переменные, mingw32_prefix , nsis_compiler и python_dir , задают местоположение файлов MinGW, компилятора NSIS и Win32 Python, соответственно, и их обычно не надо менять со значений по умолчанию, хотя NSIS может быть установлен либо в Program Files (x86) , либо в Program Files по умолчанию в зависимости от настроек Wine. Следует отметить, что setup читается оболочкой, и, следовательно, вокруг знака = не должно быть пробелов.

Компиляция

Настройка была утомительной, но это того стоило, поскольку затем компиляция станет крайне простой. Нужно запустить

в каталоге mingw32-cross-compile чтобы собрать пакет установки под Win32. На этом всё. Если процесс создания прошел успешно, выполняемый пакет установки Gwyddion под Windows вместе с предустановленным GTK+ и всем остальным будет создан в каталоге, заданном $target_prefix . Аналогично, пакет установки под Win64 собирается с помощью

Во время сборки можно сделать кофе, или изучить скрипт cross-build (он в действительности достаточно короткий и понятный).

Следует отметить, что скрипт кросс-компиляции запускает autogen.sh , но не чистит каталог с исходным кодом. Вам может понадобиться сделать это вручную если вы постоянно собираете Gwyddion. Особенно это важно, если вы собираете версии под обе архитектуры в одном и том же каталоге, убедитесь, что

был запущен между сборками чтобы привести каталог с исходным кодов в правильное состояние.

Запуск под Wine

Собранный Gwyddion может быть запущен под Wine. Предполагая значение по умолчанию target_prefix :

Чтобы запустить gwyddion.exe динамический линкер должен иметь возможность найти все нужные DLL. Это обеспечивается несколько грубым путём в скрипте copysysfiles , который копирует все необходимые файлы MinGW из системы в $target_prefix . Поскольку команда copysysfiles запускается из cross-build обычно не нужно запускать её вручную.

Второй шаг, который может понадобиться, это установка ключа реестра

таким образом, чтобы он указывал на gwyddion.exe и значения Path , чтобы оно указывало на подкаталог bin .

Кросс-компиляция отдельных модулей

Кросс-компиляция отдельных модулей требует только заголовочные файлы Gwyddion и библиотеки для разработки под Win32. Хотя их гарантированно получить кросс-компиляцией всей программы, делать это необязательно. Компилируя только библиотеки можно обойтись без установки разнообразных редких библиотек, от которых зависит Gwyddion. Это можно сделать используя патч gwyddion-2.22-build-only-libs.patch , который находится вместе со скриптами сборки.

Но ещё проще, библиотеки MinGW Gwyddion доступны как RPM-пакет mingw32-gwyddion-libs в репозитории gwyddion.net.

После того, как всё установлено можно попробовать собрать пример отдельного модуля threshold-example который доступен в репозитории subversion (или в виде пакета исходного кода). См. README там для получения дополнительной информации.

Cygwin или MinGW? Собираем программы для Windows без Windows

Содержание статьи

В общем-то, даже в Microsoft уже признали проблему и сделали WSL (Windows Subsystem for Linux), чтобы запускать те приложения, у которых нативных версий под Windows нет. Однако если ты хочешь сделать свою программу доступной для широкой аудитории, то WSL вовсе не панацея, поскольку у среднего пользователя эта система вряд ли установлена и у нативных приложений возможностей для интеграции с Windows все равно больше.

Во многих случаях камень преткновения — не сам код программы, а система сборки. Если ты используешь кросс-платформенные библиотеки и не вызываешь специфичные функции POSIX, портирование может вообще не требоваться. Главное — собрать исполняемые файлы.

Сборка-то обычно и зависит от окружения POSIX. Если ты используешь GNU autotools, то скрипт ./configure у тебя на Bourne shell. CMake и ряд других систем сборки умеют генерировать скрипты под целевую ОС, но остается последняя «маленькая» проблема — нужна проприетарная и не бесплатная ОС. Есть вариант переложить задачу ее развертывания и лицензирования на кого-то другого и обратиться к сервису вроде Appveyor. Но можно вместо этого воспользоваться способностью GCC к кросс-компиляции и собирать программы на хосте с Linux (или macOS).

GNU и Windows

Для сборки программ с помощью GNU toolchain на Windows часто используют два проекта: Cygwin и MinGW + MSYS. У них схожие цели, но разные детали реализации. Давай разбираться.

Cygwin

Cygwin — самая полная реализация окружения GNU для Windows. Он предоставляет большую часть POSIX API в виде библиотеки, что позволяет собирать программы из UNIX без портирования, если только им не требуется семантика UNIX. Яркий пример — демоны, им нужен fork() и сигналы, которых нет в Windows, да и службы Windows устроены совсем иначе.

Кроме библиотеки, дистрибутив содержит набор классических команд UNIX и терминал. Реализации команд используют эту библиотеку и поддерживают некоторые возможности UNIX, такие как регистрозависимые имена файлов.

Целевой способ использования: если нет желания или возможности портировать программу на Windows или использовать только платформенно независимые API, ее можно собрать «под Cygwin», ценой зависимости от cygwin1.dll и относительной изоляции от всей остальной системы.

Многие люди ставили и продолжают ставить окружение Cygwin, чтобы иметь возможность использовать классические команды UNIX на Windows. Некоторые разработчики также включают Cygwin в инструкции для сборки своих программ под Windows, хотя сама программа не связывается с cygwin1.dll . Для этой цели может быть более правильно использовать MSYS.

MinGW и MSYS

Если цель Cygwin — сделать возможной сборку немодифицированных приложений на Windows ценой внешней зависимости, то цель MinGW + MSYS — производить приложения без внешних зависимостей.

MinGW и MSYS — это независимые пакеты, но их часто путают и смешивают друг с другом (а часто путают и с Cygwin). Можно сказать, что MinGW — это эквивалент GCC и binutils, а MSYS — расширенный эквивалент coreutils.

Начнем с MSYS. MSYS — это более «нативная» и легковесная альтернатива Cygwin. Этот пакет включает библиотеку с реализациями функций POSIX, но она предназначена для внутреннего пользования, и авторы категорически не рекомендуют связывать с ней свои приложения.

Библиотека MSYS не реализует UNIX поверх Windows, а следует соглашениям Windows — к примеру, сознательно не учитывает регистр букв в путях к файлам. Главная цель MSYS — предоставить нужные для скриптов сборки программы вроде Bourne shell, make и прочее, что обычно требуется для autotools.

MinGW содержит версии GCC и binutils (ассемблер as, компоновщик ld и так далее), которые производят исполняемые файлы для Windows в формате PE/COFF. Здесь мы и подходим к ключевому моменту: MinGW, как и все остальные части GNU toolchain, такой же платформенно независимый проект.

Кросс-компиляция в GNU toolchain уже давно обычное дело, и в GCC целевая платформа и хост независимы друг от друга. Можно запускать GCC на Linux для x86 и собирать программы для Linux на ARM, или наоборот. Совпадать не обязаны не только рабочая и целевая архитектуры процессора. Точно так же не обязаны совпадать даже ОС и формат исполняемого файла.

Ставим MinGW

Авторы многих дистрибутивов GNU/Linux уже постарались за нас, так что многие кросс-версии GCC, включая MinGW, можно поставить из репозиториев.

Например, в Fedora:

Если ты используешь macOS, то MinGW можно поставить из Homebrew: brew install mingw-w64 .

MinGW-w64, несмотря на название, поддерживает и Win32, и Win64. Это форк MinGW, который создали в первую очередь для реализации недостающей в оригинальном проекте поддержки Win64, отсюда и название.

В Fedora также присутствует ряд готовых кросс-версий популярных библиотек, например mingw32-qt .

Hello World

Для демонстрации соберем традиционный hello world. У кросс-версий GCC всегда есть префикс, для MinGW используются префиксы i686-w64-mingw32 и x86_64-w64-mingw32 .

Тестирование кросс-компилированных программ для других архитектур — непростая задача, но, поскольку наша целевая платформа — Windows на x86, мы легко можем протестировать их в Wine:

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Кросскомпиляция программ для Windows с использованием MinGW, Boost и Cmake в openSUSE

Давным-давно в далекой-далекой галактике один программист заметил, что проект скомпилированный в VisualStudio 2005 выполняется в Windows ощутимо медленнее, чем при использовании GCC в Linux. И решил программист сравнить производительности проекта при использовании VisualStudio и GCC под Windows.

Проект является приложением, написанным на языках С и С++ с использованием библиотек Boost и системы сборки CMake.
Ниже рассказывается о создании окружения для сборки проекта на базе кросскомпилятора MinGW-w64, библиотек Boost и Cmake в openSUSE 11.3 x86.

Установка MinGW и Boost

Установка не должна представлять особой сложности. MinGW-w64 есть в репозиториях openSUSE. Для компиляции приложений для Windows x86 нужно добавить в систему репозиторий http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.3/, а для Windows x86-64 — http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_11.3/.

После добавления репозитория необходимо установить следующие пакеты:

• mingw32-cross-binutils
• mingw32-cross-cpp
• mingw32-cross-gcc
• mingw32-cross-gcc-c++
• mingw32-headers
• mingw32-libgcc
• mingw32-libstdc++
• mingw32-runtime
• mingw32-filesystem
• mingw32-boost-devel
• mingw32-libboost_date_time
• mingw32-libboost_filesystem
• mingw32-libboost_graph
• mingw32-libboost_iostreams
• mingw32-libboost_math
• mingw32-libboost_program_options
• mingw32-libboost_random
• mingw32-libboost_regex
• mingw32-libboost_serialization
• mingw32-libboost_signals
• mingw32-libboost_system
• mingw32-libboost_test
• mingw32-libboost_thread
• mingw32-libboost_wave
• mingw32-libbz2
• mingw32-libbz2-devel
• mingw32-libexpat
• mingw32-libexpat-devel
• mingw32-icu
• mingw32-libicu
• mingw32-libicu-devel
• mingw32-zlib
• mingw32-zlib-devel

После установики нужно зайти под пользователем root и в файле /usr/i686-pc-mingw32/sys-root/mingw/include/mingw_inc/_socket_types.h (или /usr/x86_64-pc-mingw32/sys-root/mingw/include/mingw_inc/_socket_types.h , если вы установили MinGW для компиляции приложений под Windows x86-64) заменить

Это связано с тем, что в BSD-сокетах дискриптор сокета знаковый тип, а в Windows — беззнаковый. Если не сделать данную замену, то приложения использующие Boost.Asio, которая в Windows ожидает беззнаковый тип SOCKET не будут компилироваться. К негативным последствиям можно отнести потенциальную возможность неправильной работы приложений, которые расчитаны на то, что тип дескриптора сокета может быть только знаковым.

На этом установка окружения завершена.
DLL файлы для распространения приложения находятся в каталоге /usr/i686-pc-mingw32/sys-root/mingw/bin ( /usr/x86_64-pc-mingw32/sys-root/mingw/bin в случае Windows x86-64). Для того, чтобы определить, какие DLL-библиотеки использует скомпилированное приложение можно воспользоваться программой Dependency Walker, которая успешно работает под wine-1.3.10.

Кросскомпиляция с использованием Cmake

Для использования кросскомпиляции в Cmake необходимо создать файл настроек, путь к которому будет передаваться cmake через задаваемый в командной строке параметр CMAKE_TOOLCHAIN_FILE . В моем случае указание пути выглядело следующим образом:

Файл i686-pc-mingw32.cmake содержал следующие настрйки:

На этом установка завершена. Теперь можно компилировать Windows-приложения прямо из рабочего оружения на Linux.

Список используемых источников

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Это «Песочница» — раздел, в который попадают дебютные посты пользователей, желающих стать полноправными участниками сообщества.

Если у вас есть приглашение, отправьте его автору понравившейся публикации — тогда её смогут прочитать и обсудить все остальные пользователи Хабра.

Чтобы исключить предвзятость при оценке, все публикации анонимны, псевдонимы показываются случайным образом.

Не надо пропускать:

• рекламные и PR-публикации
• вопросы и просьбы (для них есть Хабр Q&A);
• вакансии (используйте Хабр Карьеру)
• статьи, ранее опубликованные на других сайтах;
• статьи без правильно расставленных знаков препинания, со смайликами, с обилием восклицательных знаков, неоправданным выделением слов и предложений и другим неуместным форматированием текста;
• жалобы на компании и предоставляемые услуги;
• низкокачественные переводы;
• куски программного кода без пояснений;
• односложные статьи;
• статьи, слабо относящиеся к или не относящиеся к ней вовсе.