Кросс компиляторы для 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 там для получения дополнительной информации.

Кросскомпиляция программ для 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);
• вакансии (используйте Хабр Карьеру)
• статьи, ранее опубликованные на других сайтах;
• статьи без правильно расставленных знаков препинания, со смайликами, с обилием восклицательных знаков, неоправданным выделением слов и предложений и другим неуместным форматированием текста;
• жалобы на компании и предоставляемые услуги;
• низкокачественные переводы;
• куски программного кода без пояснений;
• односложные статьи;
• статьи, слабо относящиеся к или не относящиеся к ней вовсе.

Кросс-компиляция и отладка C++ Windows-приложения под Linux

Показали мне недавно интересное приложение, под которое можно разрабатывать плагины. Приложение оказалось очень полезным для научной работы, но вот незадача — приложение разработано под Windows, у меня стоит Ubuntu. Windows для разработки под это приложение от лаборатории получить пока не удалось. Чтобы не тратить время, решил освоить кросс-компиляцию и отладку этого приложения.

Итого, имеется:
Ubuntu 12.10 x64
Не-юникодное приложение Мастерская Граф-Моделей (МГМ) (В командах консоли будет называться gmw.exe)

Нужно:
Разрабатывать и отлаживать плагины (dll-библиотеки), не устанавливая Windows.

И тут нам помогут Wine, Code::Blocks, портированное GDB, и boost.

Wine, не юникодное приложение, английский интерфейс Ubuntu и русский язык

При попытке открыть не юникодное приложение под Wine

получаются зюки следующего вида:

На эту проблему интернет очень быстро дает следующую подсказку:

В моём случае, данный подход не улучшил ситуацию ни на йоту.
Как выяснилось, русских локалей в системе не было добавлено (тыц).

Теперь запускаем с выше-указанной подсказкой

И, вуаля, запускается приложение с читаемым русским текстом:

Настройка IDE Code::Blocks для кросс-компиляции и отладки

Установка Code::Blocks

В дальнейшем для отладки нам потребуется менять код плагина отладки поэтому лучше сразу взять версию Code::Blocks из под svn.
Устанавливаем svn:

С помощью svn получаем код C::B, для этого переходим в папку, в которую хотим сохранить код C::B, где и набираем:

Переходим в полученную папку ‘trunk’.

Компиляция C::B происходит с помощью g++, autotools, automake и некоторых других утилит, которые необходимо установить:

Кроме того Code::Blocks зависит от wxWidgets:

Подстраиваем установщик под компьютер (можно запускать единожды):

И дальше, устанавливаем сам codeblocks (ключ —prefix можно упустить для использования настроек по-умолчанию):

Более подробно можно посмотреть по ссылке.

Настройка компиляции и линковки

Выполняем пункты с 1 по 5 с форума Code::Blocks. После этого компиляция программ должна работать, если не используется линковка к платформо-зависмым библиотекам (линковка с boost::regexp будет рассмотрена позже).
(*) В новом Code::Blocks немного изменилось меню по сравнению с инструкцией. Настройки искать нужно в ‘Settings->Compiler. ‘. Для старого Code::Blocks (10.05) пункт 5 нужно выполнить полностью, для нового же (12.11) настройку касающуюся gdb в 5 пункте пока трогать не будем.

Если используется boost его лучше положить отдельно от /usr/include, т.к. по этому адресу лежит много linux-специфичных заголовочных файлов, которые мы не хотим включать в проект при компиляции под Windows.

UPD: При настройке линковки в поле «Other Linker Options» имеет смысл добавить опцию «-Wl,—subsystem,windows,—kill-at», которая помечает, что это реально Windows DLL, и, что самое главное, запрещает использовать декорирование символов (—kill-at) при экспорте функций с соглашением вызова __stdcall. Подрбнее здесь и здесь.

Начиная с пункта 7 по ссылке выше, описывается кросс-отладка, но, к сожалению, insight.exe, упоминающийся в инструкциях, найти не удается. Поэтому пойдем своим путем.

Кросс-отладка в Code::Blocks & MingW32 gdb для Windows

gdb, который является родным для линукса частично умеет отлаживать Windows приложения, правда, умеет он только останавливаться на исключениях и почти всегда игнорирует точки останова. Чтобы справиться с этими проблемами скачиваем gdb в пакете mingw32 под Windows. Для этого скачиваем и затем распаковываем и переходим в подпапку ‘bin’. Устанавливаем gdb под Windows:

Теперь в этой же папке bin появился файл gdb.exe, он-то нам и нужен.

Создаем скрипт для имитации обычного gdb для этого в файл /usr/bin/i586-mingw32msvc-gdb

Заносим следующие строки:

Для старого C::B все уже настроенно, для нового же отладчик нужно настроить дополнительно. В пункте ‘Settings->Debugger’ кликаем по ‘GDB/CDB debugger’ затем по ‘Create Config’. В новом конфиге меняем команду запуска отладчика на ‘/usr/bin/i586-mingw32msvc-gdb’, остальные настройки по желанию. После этого идем в ‘Settings->Compiler. «, в пункте ‘Selected Compiler’ выбираем тот компилятор, который настраивали до этого и затем на вкладке ‘Toolchain executables’ меняем ‘Debugger’ на наш свежесозданный конфиг. Теперь отладчик будет останавливаться на точках останова, хотя и остановить программу в произволльный момент не сможет (данная проблема пока еще не решена). Правда при попытке отладить,C::B выдает следующую ошибку:

Эта ошибка говорит о том, что плагин отладчика в C::B не понимает выдачу отладчика gdb.exe. Как выяснилось при ближайшем рассмотрении плагин отладчика имеет платформо-зависимый код, и вот тут-то и нужно вспомнить что у нас есть исходники C::B. Мы сейчас слегка подкоррекируем код этого плагина. Нужно будет поменять код только одного файла ‘/src/plugins/debuggergdb/gdb_driver.cpp’
Для этого нужно перейти в корень проекта C::B (откуда запускалась команды ./bootstrap), по умолчанию это папка ‘trunk’. И накактить патч:

Ну и пересобираем Code::Blocks:

И почти все готово, остается только создать проект. Шаги 12-13 по ссылке. Если же вы хотите создать проект dll-библиотеки, то указывайти создание динамической библиотеки в мастере и переименовывайте разширение в dll.
Проверям, что в настройках проекта стоит выбранная нами цепь компилятор-линкер-отладчик. ‘<Правая клавиша на проект>-Build Options. ‘ пункт ‘Selected compiler’, и можно радоваться и отлаживаться. Напомню, что по какой-то причине отладчик не может быть прерван во время исполнения, т.е. все отладочные действия могут буть применены только во время останова программы. В частности нельзя поставить новую точку останова, если программа не стоит на какой-либо другой точке останова…

Линкование статической библиотеки boost’а

Библиотека boost в основном является набором заголовочных файлов, и потому никаких проблем с линковкой обычно не возникает. Но для некоторых частей boost’а необходимо линковаться к статической библиотеке, например, boost::regex. Пробуем собрать проект и получаем:

Ошибка возникает из-за того, что мы пытаемся прилинковаться к linux билиотеке, для того чтобы построить windows-приложение.
Чтобы слинковаться нужно скомпилировать boost::regex с помощью MingW32 (про кросс-компиляцию). Скачиваем boost, распаковываем и переходим в папку с распаковынным boost’ом. Создаем файл user-config.jam в корне домашней директории:

Со следующим содержанием:

Дальше настраиваем сборку и собираем:

После выполнения последней команды у меня были ошибки «failed updating 1 target», что, правда, не мешает собираться программам.

В результате, у нас есть полностью подготовленная среда для написания, сборки и отладки Windows-приложений или Windows-библиотек из под Linux. Теперь можно приступать к работе…