Сборка mingw в windows своими руками

В сети можно найти много описаний сборки mingw и GNU утилит под ним. Я тоже решил написать свой вариант, так как во-первых он на русском. Во-вторых используются последние стабильные исходники (по состоянию на 27.01.2011). В третьих добавлена оптимизация циклов (graphite loop optimizations). В четвертых я описываю причины выбора тех или иных опций конфигурации исходников. В пятых, чтобы не забыть.

Зачем собирать mingw самому?

• Для того, чтобы сконфигурировать компоненты так как нужно мне, а не той тысяче пользователей, которые скачивают стандартный пакет с официального сайта.
• Чтобы я сам определял какие компоненты мне нужны в виде shared библиотек с dll-ками, а какие я линкую статически.
• Чтобы быть уверенным, что gcc работает максимально эффективно.
• Чтобы исключить возможные закладки в исполняемые модули.
• Чтобы лучше понять как собираются и устанавливаются GNU утилиты.

Каждый может найти причину для собственноручной сборки.

Что понадобится?

Как ни странно, но для сборки mingw нужен сам mingw. Товарищи постарались и сделали аккуратную программу установки, которая сама скачает и установит нужные пакеты. Она лежит на официальном сайте.
Помимо самого mingw при установке выбираем «C++ Compiler» и «MinGW Developer ToolKit». Ставим в C:\MinGW.

Качаем исходники:

• gmp-5.0.1
• ppl-0.11
• cloog-ppl-0.15.10
• mpfr-3.0.0
• mpc-0.8.2
• binutils-2.21
• mingwrt-3.18
• w32api-3.15-1
• libiconv-1.13.1
• gcc-4.5.2

Опционально:

• make-3.82

Не обойтись без терпения, настойчивости и удачи!

Сборка

Создаем на самом быстром винчейстере рабочую папочку C:\mbuild. Все исходники складываем в C:\mbuild\distrib. Выращивать mingw будем в C:\mbuild\release. Запускаем скачанный msys…

cd /c/mbuild

Небольшое замечание. В большинстве инструкций сказано сложить исходники gmp, mpfr и mpc в папку к gcc — он соберет их автоматически. Мы так делать не будем, потому что ходим прикрутить к gcc CLooP, а он зависит от gmp. То есть нам придется собирать gmp до того, как мы приступим к конфигурации gcc.

GMP

tar -xjf distrib/gmp-5.0.1.tar.bz2 && cd gmp-5.0.1
mkdir build && cd build
../configure —prefix=’/c/mbuild/release’ —enable-cxx —disable-static —enable-shared CPPFLAGS=’-fexceptions’ &>config.my.log
make -j4 &>make.my.log
make install &>install.my.log

• —enable-cxx CPPFLAGS=’-fexceptions’ — Обязательны для корректной сборки ppl
• —disable-static —enable-shared — В windows нельзя одновременно иметь shared и static версии, иначе сборка дальнейших компонентов может завершиться ошибкой. Будем собирать shared версии. Не волнуйтесь, на компилируемые с помощью mingw программы зависимость не переносится.

Очень важно не использовать ключи оптимизации CFLAGS, CXXFLAGS и LDFLAGS такие как «-s -O2 -mtune=i686» — бывали случаи когда ppl из-за этого не находил gmp.

PPL

tar -xjf ../../distrib/ppl-0.11.tar.bz2 && cd ppl-0.11
mkdir build && cd build
../configure —prefix=’/c/mbuild/release’ —disable-static —enable-shared —disable-nls —enable-threads —disable-debugging —with-gmp-prefix=/c/mbuild/release —with-cflags=’-s -O2′ —with-cxxflags=’-s -O2′ &>config.my.log
make -j4 &>make.my.log
make install &>install.my.log

• —disable-static —enable-shared — какой вариант линковки мы выбрали для gmp такой же следует выбрать и для ppl.
• —disable-nls — отключая National Language Support не будем требовать от приложения умения общаться на русском.
• —enable-threads — создаваемый mingw я буду использовать для компиляции многопоточных приложений.
• —disable-debugging — отладочная информация ни к чему — она занимает лишнее место.
• —with-gmp-prefix — сообщит где искать gmp.
• —with-cflags —with-cxxflags — некоторая оптимизация.

Во время конфигурирования windows может сообщать о том, что программа conftest не запустилась. Не паникуйте — это всего лишь результат работы скрипта configure.

CLooG/PPL

tar -zxf ../distrib/clog-ppl-0.15.10.tar.gz
cd cloog-ppl-0.15.10
mkdir build && cd build
../configure —prefix=’/c/mbuild/release’ —disable-static —enable-shared —with-ppl=/c/mbuild/release —with-gmp=/c/mbuild/release CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make &>make.my.log

Тут имеется неприятная часть со скриптами конфигурации. Их почему-то просто нет. В логе make.my.log сообщается, что папка m4 отсутствует. Я не разбираюсь в причинах ее отсутствия. Просто копирую ее из ppl-0.11. Благо там имеются нужные скрипты.

make &>make.my.log
make install &>install.my.log

Опции понятны из предыдущих описаний.

MPFR

tar -xjf distrib/mpfr-3.0.0.tar.bz2 && cd mpfr-3.0.0
mkdir build && cd build
../configure —prefix=’/c/mbuild/release’ —disable-static —enable-shared —enable-thread-safe —with-gmp=/c/mbuild/release CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make -j4 &>make.my.log
make install &>install.my.log

MPC

tar -xzf distrib/mpc-0.8.2.tar.gz
cd mpc-0.8.2
mkdir build && cd build
../configure —prefix=/c/mbuild/release —disable-static —enable-shared —with-gmp=/c/mbuild/release —with-mpfr=/c/mbuild/release CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make -j4 &>make.my.log
make install &>install.my.log

LIBICONV

tar -xzf distrib/libiconv-1.13.1.tar.gz && cd libiconv-1.13.1
mkdir build && cd build
../configure —prefix=/c/mbuild/release —enable-shared —disable-static —disable-nls CFLAGS=’-s -O2 -mno-cygwin’ CPPFLAGS=’-s -O2 -mno-cygwin’ &>confgi.my.log
make -j4 &>make.my.log
make install &>install.my.log

Вообще, libiconv необязателен, но включить его поддержку желательно (очень полезно, если вы будете собирать другие gnu утилиты этим mingw).

• CFLAGS=’-mno-cygwin’ Для того, чтобы libiconv корректно собирался под msys следует явно указать, что мы используем не CygWin.

BINUTILS

tar -xjf distrib/binutils-2.21.tar.bz2 && cd binutils-2.21
mkdir build && cd build
../configure —prefix=/c/mbuild/release —disable-nls —enable-threads —with-gmp=/c/mbuild/release —with-mpc=/c/mbuild/release —with-mpfr=/c/mbuild/release —with-ppl=/c/mbuild/release —disable-ppl-version-check —with-cloog=/c/mbuild/release —disable-cloog-version-check CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make -j4 &>make.my.log
make install &>install.my.log

• —disable-ppl-version-check —disable-cloog-version-check Когда то столкнулся с тем, что скрипты проверки версии ppl искали именно 10 версию, а не выше, по инерции использую теперь эти опции, хотя кое-где ситуацию уже исправили. Если есть желание можете покопаться в configure скрипте, посмотрев обработку ppl_version_minor. Binutils-2.21 конфигурируется нормально, а gcc-4.5.2 — нет.

INCLUDE

Распаковываем C:\mbuild\distrib\w32api-3.14-mingw32-src.tar.lzma в C:\mbuild\w32api. Именно в w32api, чтобы ее мог найти mingwrt при сборке.

tar -xzf distrib/mingwrt-3.18-mingw32-src.tar.gz
cp -r w32api/include /c/mbuid/release
cp -r mingwrt-3.18-mingw32/include /c/mbuild/release

Чтобы верно находились все длл-ки при конфигурации, добавим путь к релизу в PATH

export PATH= $PATH:/c/mbuild/release

GCC

tar -xjf gcc-4.5.2.tar.bz2
cd gcc-4.5.2
mkdir build && cd build
../configure —prefix=/c/mbuild/release —enable-shared=libstdc++ —enable-threads —enable-version-specific-runtime-libs —enable-languages=c,c++ —with-dwarf2 —disable-sjlj-exceptions —disable-win32-registry —disable-werror —disable-nls —disable-multilib —with-gmp=/c/mbuild/release —with-ppl=/c/mbuild/release —disable-ppl-version-check —with-cloog=/c/mbuild/release —disable-cloog-version-check —with-mpfr=/c/mbuild/release —with-mpc=/c/mbuild/release —enable-libgomp —with-libiconv-prefix=/c/mbuild/release —enable-libstdcxx-debug —enable-cxx-flags=’-s -O2′ —with-boot-ldflags=’-s’ &>config.my.log
make -j4 BOOT_CFLAGS=’-s -O2′ BOOT_CPPFLAGS=’-s -O2′ &>make.my.log

Самая длительная и ответственная часть. Я исользую именно полный исходник
gcc, а не отдельно gcc-core и gcc-с++ так как включаю libgomp и zlib, а
они не идут в составе gcc-core.

• —enable-shared=libstdc++ — Обычно я компилирую библиотеки статически, но иногда приходится использовать stlport вместо родной STL, поэтому ее сделаем орываемой.
• —enable-version-specific-runtime-libs Влияет на расположение заголовочных файлов и библиотек runtime. Эта опция нужна для того, чтобы обеспечить возможность использования нескольких версий runtime библиотек с одной mingw.
• —enable-languages=c,c++ — собираем компилятор для языков C и C++.
• —with-dwarf2 — отладочная информация dwarf-2
• —disable-sjlj-exceptions — отключить sjlj исключения
• —disable-win32-registry — модно настроить gcc таким образом, чтобы информацию об include папке он искал в реестре windows. Нас это не интересует.
• —disable-werror — werror хорошо, когда его задаешь вручную.
• —disable-nls эта опция не влияет на locale и все что связано с широкими символами в mingw. Их поддержка будет неполной (например некорректно работает получение текущей пользовательской локали — std::locale(«») всегда вернет locale(«C»)) даже если мы разрешим NLS. Эта опция влияет лишь на сообщения компилятора. Лично мне было бы непривычно, если бы он заговорил по русски…
• —disable-multilib — будем использовать наш компилятор для создания windows программ и только
• —enable-libstdcxx-debug эта опция позволяет помимо основной версии stdc++ библиотеки иметь отладочную, чтобы можно было во время отладки путешествовать и по библиотечным функциям.

К сожалению с отладочной информацией собирается не только версия, которую мы подключили ключом —enable-libstdcxx-debug, но и основная. Побороть это с помощью опций сборки gcc я не смог. Поэтому предлагаю следующий вариант:

cd i686-pc-mingw/libstdc++-v3
make -j4 CFLAGS=’-s -O2′ CXXFLAGS=’-s -O2′ &>make.my.log

Тут мы несколько смухлевали. В реальности (в том числе, когда бы собираете кросс-компилятор) вам придется собрать сначала сам gcc с помощью make all-gcc, затем runtime и только потом завершить сборку всего gcc. Процесс описан, к примеру тут. Но мы не будем заморачиваться, так как в этом конкретном случае все работает и так.

cd ../../
make install &>install.my.log

К сожалению мне никогда не удавалось скомпилить gcc под mingw с использованием профилирования (make profiledbootstrap) — процесс завершался с ошибками. Чаще всего segmentation fault компилятора. А жаль… говорят прирост в скорости компиляции ~7%.

Runtime и W32API

w32api нужно собирать с помощью нового gcc. Для этого в файле fstab (поумолчанию C:\MinGW\msys\1.0\etc\fstab) меняем C:\MinGW на C:\mbuild\release и запускаем новый msys. В этом экземпляре msys используется вновьсобранный gcc. Но так как от зависимостей мы еще не избавились, нам придется сообщить msys где искать dll-ки старого mingw:

export PATH=$PATH:/c/MinGW/bin

W32API

cd ../../w32api
mkdir build && cd build
../configure —prefix=/c/mbuild/release CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make &>make.my.log
make install &>install.my.log

MingwRT

tar -xzf distrib/mingwrt-3.18-mingw32-src.tar.gz && cd mingwrt-3.18-mingw32-src
mkdir build && cd build
../configure —prefix=/c/mbuild/release CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make &>make.my.log
make install &>install.my.log

Из-за того, что gmp собирался не родным gcc он, скорее всего, имеет зависимости от libstdc++.dll и libgcc_s_dw2-1.dll. Первая была собрана с родным gcc, вторую придется скопировать из старого mingw. Как вариант можно пересобрать gmp в новом gcc для избавления от завимисотей.
Для уменьшения размера можете смело поудалять ненужные папки. Например share/doc.

Почти все. Для комфортной работы нам надо еще собрать make.

MAKE

tar -xjf distrib/make-3.82.tar.bz2 && cd make-3.82
./configure —disable-nls —with-libiconv-prefix=’/mingw’ CFLAGS=’-s -O2′ CPPFLAGS=’-s -O2′ &>config.my.log
make -j4 &>make.my.log
cp make.exe /c/mbuild/release/bin/mingw32-make.exe

Теперь все. в папочке C:\mbuild\release получили свой аккуратный mingw. Добавляем пакетов по вкусу, оборачиваем в аккуратный скрипт и получим что-то вроде nuwen mingw. Удачных сборок!

Постскриптум: Скачанный нами пакет mingw кроме того содержит:

• mingw32-autoconf
• mingw32-automake
• mingw32-autotools
• mingw32-basic-dsdtar
• mingw32-bzip2
• mingw32-cygutils
• mingw32-expat
• mingw32-gdb
• mingw32-gendef
• mingw32-gettext
• mingw32-libarchive
• mingw32-libtool
• mingw32-mingw-get
• mingw32-mingw-utils
• mingw32-package-list
• mingw32-pdcurses
• mingw32-pexports
• mingw32-popt
• mingw32-pthreads-w32
• mingw32-xz

MinGW — c и c++ компилятор для Windows

Если говорить о релизах современных видеоигр, то всегда возникает вопрос о многоплатформенной поддержке. Когда вы создаете браузерную игру, браузер — это ваша платформа, и вы действительно не беспокоитесь об ОС под ней. При использовании популярного движка вы можете проверить, работают ли различные версии, но вы все еще в основном полагаетесь на способность оригинальных разработчиков заставить его работать на всех платформах.

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

Одним из способов сделать это, конечно, является наличие машины, работающей на указанной платформе (возможно, в режиме мультизагрузки), которая поставляется со своим собственным набором неприятностей. Другое решение — кросс – компиляция, и именно это я вкратце опишу здесь.

Войдите в MinGW

Для кросс-компиляции программ на C / C++ большинство разработчиков используют MinGW – минималистичный GNU для Windows, который, как следует из названия, представляет собой набор программ (порты gcc, gdb и т. Д.), заголовков и статических библиотек, позволяющих кросс-компиляцию материала для MS Windows на других платформах.

Настройка среды MinGW с нуля может быть утомительной, но, к счастью, самый популярный дистрибутивный пакет MinGW сам по себе и порты MinGW некоторых библиотек находятся в их репозиториях. Установить компилятор MinGW из дистрибутива так же просто, как и любое другое программное обеспечение.

# При установке на 64-битную Windows

# При установке на 32-битную Windows

Настройка процесса сборки

Как только вы установили компилятор, пришло время взглянуть на ваш собственный проект и его систему сборки.

С make

Если вы используете make для управления процессом сборки, то, скорее всего, ваш Makefile уже отлично работает для кросс-компиляции, и вам не нужно будет вносить никаких изменений.

В принципе, на этом этапе есть два требования:

Если вы используете жестко закодированное имя компилятора или флаги, то пришло время отредактировать файл Makefile и привести его в форму. Как только все это будет сделано, просто укажите флаги кросс-компилятора MinGW и специфичного для Windows компоновщика, и все готово.

# Для 64-битных сборок

# Для 32-битных сборок; аналогично приведенному выше, отличается только имя компилятора

user$ CC=i686-w64-mingw32-gcc LDLIBS=-lmingw32 make [args…]

Если вы компилируете C++, а не C, вы захотите использовать переменную CXX и …компилятор mingw32-gcc-g++.

С CMake

При использовании CMake вам нужно будет внести одно небольшое изменение в ваш CMakeLists.txt: то есть добавление библиотеки mingw32 в вашуtarget_link_libraries(). Вы можете посмеяться над этим и сказать: «О, я могу просто использовать — DCMAKE_EXE_LINKER_FLAGS», но проблема с использованием этой переменной заключается в том, что при вызове компилятора содержимое переменной помещается перед именами объектов, например:

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

При указании библиотек через target_link_libraries () команда строится с именами библиотек, следующими за именами объектов, и все заканчивается прекрасно и денди. Как только вы внесете указанное изменение, продолжайте запускать CMake с помощью файла MinGWtoolchain.

# Для 64-битных сборок; другие дистрибутивы могут поместить файл toolchain под другой путь

# Для 32-битных сборок; то же самое, что и выше, но с использованием 32-битного профиля

# Как только файлы сборки будут сгенерированы с помощью правильного файла toolchain,
# вам больше не нужно ссылаться на него, и вы можете просто выполнить обычную сборку

Если вам кажется, что ваш дистрибутив не предоставляет готовый файл toolchain, вы можете попробовать взять его из Fedora и соответствующим образом отредактировать

Особенности библиотек

В зависимости от используемых библиотек могут потребоваться некоторые дополнительные шаги. Например, при использовании SDL2 вам также нужно будет добавить библиотеку SDL2main к флагам компоновщика. Причина этого заключается в том, что в MS Windows существует строгое разделение между «консольными» и «ГРАФИЧЕСКИМИ» программами – первые всегда порождают cmd.exe window (оболочка MS Windows), где они выполняют свой stdin/stdout IO, в то время как у вторых этого нет.

В то время как консольные программы начинают свое выполнение с функции main (), графические программы обычно начинают свое выполнение с функции WinMain ().

Чтобы избавить вас от необходимости иметь две версии вашей основной функции, статическая библиотека SDL2main предоставляет свою собственную реализацию WinMain(), которая выполняет некоторый дополнительный код инициализации SDL, а затем вызывает вашу основную функцию ().

Этот подход обычно встречается в других библиотеках – например, библиотеки программирования игр Allegro и SFML предоставляют свои соответствующие статические библиотеки allegro_main и sfml-main.

А как насчет этих зависимостей?

Написание игры с использованием собственного движка уже является мазохизмом, поэтому, если вы не пытаетесь достичь новых крайностей и используете только собственные API, ваша игра, вероятно, зависит от какой-то популярной мультимедийной библиотеки, такой как Allegro, SDL или SFML. Чтобы успешно скомпилировать вашу игру для MS Windows, вам также нужно позаботиться об этом.

Простой способ: установка зависимостей из дистрибутива репо

Если вам посчастливилось и весь ваш набор зависимостей имеет версии MinGW, доступные в менеджере пакетов, то просто установите что-нибудь из репозитория, и все будет в порядке.

Способ средней сложности: установка предварительно скомпилированных зависимостей вручную

Хотя описанный выше сценарий, безусловно, самый простой, обработка зависимостей не так уж и сложна, если их авторы предоставляют файлы разработки MinGW. Например, рассмотрим библиотеку Аллегро. Релизы на GitHub содержат множество загружаемых вариантов каждой версии, среди которых есть наборы MinGWdev. Если вы загрузите один из них (выберите тот, который подходит для вашей цели кросс-компиляции) и распакуете архив, вы увидите такую структуру каталогов:

Сложный способ: компиляция зависимостей из исходного кода

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

По моему опыту, самая трудная часть компиляции всей цепочки зависимостей-это настройка каждого файла Makefile / CMakeLists.txt когда вы идете, чтобы заставить каждую библиотеку распознавать, где находятся ее зависимости – хотя вы можете избежать этого, установив каждую скомпилированную библиотеку в корневой каталог MinGW (если вы не возражаете против беспорядка, то есть).

Библиотеки DLL

Как только вы скомпилируете свою игру, последнее, что вам остается сделать, — это упаковать и опубликовать ее. Но для правильной работы исполняемого файла вам понадобятся все библиотеки DLL, от которых он зависит. Чтобы узнать, какие общие объекты динамически загружаемые библиотеки необходимы, вы можете использовать программу objdump:

Теперь, когда вы знаете, какие библиотеки DLL необходимы, вам нужно найти и скопировать их. Если вы хотите сделать это вручную, имейте в виду, что библиотеки DLL могут зависеть от других библиотек DLL, поэтому захвата только прямых зависимостей EXE-файла вашей игры может быть недостаточно. Если вы ищете простой, автоматизированный способ, вы можете использовать copydeps, небольшую программу на Python, которая отлично подходит именно для этой цели.

Источник

Космодром на коленке

пятница, 19 июня 2009 г.

Установка MinGW

Ниже я перечислю основные особенности MinGW и опишу несколько способов для его установки.

Для начала перечислю важные (на мой взгляд) особенности MinGW. 😉

Основные достоинства:
+ полностью бесплатен;
+ генерирует хороший быстрый код;
+ непрерывно развивается;
+ удобство и компактность установки.

Основные недостатки:
— Относительно медленная компиляция C++ кода;
— Относительно медленная линковка результирующего файла;
— Несовместимость с, содержащими C++ классы, *.lib и *.dll файлами созданными в MS Visual Studio. По этой причине MinGW и PhysX SDK не дружат друг с другом..

Для того чтобы заполучить на свой компьютер готовый к работе MinGW, существует несколько способов.

Способ 1- использовать автоматический установщик с официального сайта MinGW.
Установщик официальной версии MinGW следует искать на сайте http://mingw.org/
На момент написания этих строк файл установщика называется «MinGW-5.1.4.exe» и его можно загрузить со страницы загрузки.
Установщик состоит из одного файла «MinGW-5.1.4.exe» и имеет мизерный разер (

140 KB). Непосредственно при установке он выкачивает дополнительные архивы с компонентами GCC. По умолчанию MinGW ставиться в папку «c:\mingw» Перед установкой рекомендую поместить «MinGW-5.1.4.exe» в отдельную пустую папку, т.к. все выкаченные архивы кэшируются в папке откуда запущена установка. Если ничего не удалять, то можно все это добро скопировать и устанавливать без интернета, запуская все тот же «MinGW-5.1.4.exe».

Следует отметить, что при установке через «MinGW-5.1.4.exe», можно выбрать версию Mingw (Previous, Current, Candidate), инсталлятор регистрирует установку в системе и предоставляет возможность обновления и удаления текущей установки.
Если MinGW ставится для работы с Code::Blocks, то при установке рекомендую выбрать версию «Candidate», а среди устанавливаемых компонентов должны быть обязательно отмечены «MinGW base tools», «g++ compiller» и «MinGW Make».

gdb-6.8-mingw-3.tar.bz2
mingw32-make-3.81-2.tar.gz
binutils-2.18.50-20080109-2.tar.gz
gcc-g++-3.4.5-20060117-3.tar.gz
w32api-3.13-mingw32-dev.tar.gz
mingwrt-3.15.2-mingw32-dev.tar.gz
gcc-core-3.4.5-20060117-3.tar.gz

Не нужно даже прибегать к запуску инсталлятора, достаточно просто разархивировать все архивы в одну папку. Для распаковки можно воспользоваться замечательным бесплатным архиватором 7-zip (http://www.7-zip.org/).

И еще, отладчик gdb (который будет очень кстати при работе в среде Code::Blocks) придется качать отдельно в секции загрузки http://mingw.org

Примером может служить пакет MinGW С++ Toolbox предлагаемый (в связке с Code::Blocks 😉 в качестве альтернативного инструментария для сборки и работы с движком рендеринга Ogre. Никаких специфических ограничений и заточек под Ogre в нем нет, и я давно использовал его просто как удобный «все-в-одном» инсталлятор MinGW. Все было замечательно. 🙂 Но однажды случилось страшное.. В очередной раз решив собрать свежий Ogre, потыкать примеры и заставить себя чего-нибудь на нем слепить, я обнаружил что исходники относительно недавно вышедшего Ogre 1.6.2 у меня просто не собираются этим пакетом инструментов (требуется обновление w32api до версии 3.13). К слову, установка MinGW версии Candidate первым способом позволила решить эту проблему. 😉 Хотя данный пакет в целом не плох и ранее всегда справлялся со своими задачами. Если требуется компактный инсталлятор со стабильным MinGW для общих задач, то можно со спокойной душой качать MinGW_Toolbox_Setup_wr1 c ogre3d.org. Будем наедятся что актуальная версия этого пакета появится в скором времени.

Если поискать, то в интернете, можно найти и другие сборки MinGW от энтузиастов. Как правило это просто само-распаковывающихся архивы.

Думаю на сегодня хватит про MinGW.

В ближайшее время постараюсь (как и обещал ранее) написать про установку ночных сборок Code::Blocks и их первичную настройку.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

MinGW (Minimalist GNU for Windows)

MinGW (Minimalist GNU for Windows), ранее mingw32 — бесплатная среда разработки родных приложений под Microsoft Windows с открытым исходным кодом. Состоит из портированного GNU Compiler Collection, GNU Binutils (ассемблер, компоновщик, менеджер архивации), GNU Debugger, набора свободно распространяемых библиотек импорта и заголовочных файлов для Microsoft Windows API и прочего.

MinGW не нуждается в DLL-слое совместимости, и поэтому, если в программе не используется лицензия GPL, программы не обязательно распространять вместе с исходным кодом.

MinGW может использоваться как на своей родной платформе Microsoft Windows, так и на UNIX-подобных и на Cygwin

Также, другими авторами в качестве альтернативы MinGW, был разработан компилятор MinGW-w64, который поддерживает 64-х битные системы. Сначала он был предложен на рассмотрение для интеграции с оригинальным проектом MinGW, но был отклонен в связи с подозрением на использование несвободного кода. В дальнейшем, разработчики MinGW-w64 отказались от дальнейшего сотрудничества с MinGW.

Содержание

История

Изначально MinGW назывался mingw32, но впоследствии от этого названия отказались, чтобы подчеркнуть, что MinGW не ограничен 32-битными системами. Первый релиз, созданный Колином Петерсом в 1998 году, включал в себя только порт GCC из Cygwin. Ян-Яап ван дер Хайден создал первый нативный Windows-порт GCC, добавив также binutils и make. Мумит Кхан позже принял участие в разработке, добавив в комплект больше специфичных для Windows возможностей, включая заголовочные файлы Win32, написанные Андершом Нурландером. Чтобы получить большую поддержку общественности и централизовать разработку, в 2000 проект был перемещён на SourceForge.net, где в сентябре 2005 был выбран проектом месяца.

Поддержка языков программирования

Большинство языков, которые поддерживаются GCC, поддерживаются и в MinGW. Среди них C, C++, Objective-C, Objective-C++, Fortran и Ada. Также используются библиотека из GCC (libstdc++ for C++, libgfortran for Fortran, др.)

Необходимо отметить, что GCC не включает в себя библиотеку языка C. По умолчанию MinGW подключается к предоставляемой Windows библиотеке MSVCRT, к которой так же подключался Microsoft Visual Studio 6.0 1998 года. Библиотека не поддерживает стандарт C99, так как его ещё не существовало к моменту выпуска MSVCRT. Стандарт C89 поддерживается, однако не полностью. MSVCRT не изменялась в течение многих лет, и в будущем каких-либо изменений не ожидается. Новые версии Visual Studio используют новые исполняемые библиотеки, однако они не всегда предоставляются операционной системой или не являются свободно распространяемыми, что затрудняет работу с открытым программным обеспечением.

По причине использования MSVCRT, MinGW имеет множество ограничений и особенностей с совместимостью как и Microsoft Visual Studio 6.0. При разработке не следует полагаться на C99, только на C89. К примеру, новый формат символов в printf %a и %ll не поддерживается (хотя для последнего существует обходное решение).

Разработчики MinGW пытались разрешить подобные проблемы во вспомогательной библиотеке mingwex (или более точно libmingwex). Сейчас она достаточно далека от совершенства и, вполне вероятно, что работа над ней останется незавершённой. Для примера, добавление поддержки %a в ранее упомянутый, printf потребовало бы полное изменение устройства функции. Использование библиотеки glibc не помогло в решении проблемы из-за её лицензии. [Источник 2] Однако, проблема разрешилась в MinGW-w64, где к тому же обеспечивается полной соответствие стандартам POSIX.

Компоненты MinGW

Сравнение с Cygwin

MinGW является форком от Cygwin версии 1.3.3. Несмотря на то, что и Cygwin, и MinGW используются для портирования программного обеспечения Unix под Windows, они используют разный подход: цель Cygwin — предоставить полный слой POSIX, включающий в себя реализацию всех основных системных вызовов и библиотек системы UNIX, жертвуя производительностью там, где это необходимо для совместимости. Целью MinGW является предоставление нативной функциональности и производительности посредством прямых вызовов Windows API. В отличие от Cygwin, MinGW не нуждается в DLL-слое совместимости и, таким образом, программы не обязаны распространяться с исходным кодом. Программы под Windows, написанные с Cygwin, должны запускаться поверх копилефтной библиотеки совместимости, которая должна распространяться с программой, а также с исходным кодом программы.

Комбинация MinGW и MSYS предоставляет небольшую независимую среду, которая может быть загружена на съемные носители, не требуя добавления записей в файлы реестра. Cygwin, предоставляя бо́льшую функциональность, является более сложным для установки и поддержки.

Также возможна кросс-компиляция приложений Microsoft Windows с MinGW-GCC под управлением операционных систем семейства POSIX. Это означает, что разработчику не нужно устанавливать Windows с MSYS, чтобы скомпилировать программы, которые будут запускаться под Microsoft Windows без Cygwin.

MinGW-w64

В связи с тем, что в рамках изначального проекта MinGW не обещалось, что в его кодовую базу будут вноситься обновления, связанные с добавлением некоторых новых ключевых элементов Win32 API, а также наиболее необходимой поддержки 64-битной архитектуры, был создан проект MinGW-w64. Он является новой чистой реализацией портирования GNU Compiler Collection (GCC) под Microsoft Windows, осуществленной изначально компанией OneVision и переданной в 2008 году в общественное пользование (Public Domain). Сначала он был предложен на рассмотрение для интеграции с оригинальным проектом MinGW, но был отклонен в связи с подозрением на использование несвободного или проприетарного кода. По многим серьезным причинам этического характера, связанным с отношением со стороны авторов MinGW, ведущие разработчики кода MinGW-w64 решили больше не пытаться кооперироваться с проектом MinGW.

MinGW-w64 обеспечивает более полную реализацию Win32 API, включая:

Установка

Сборка Mingw в Windows своими руками

Зачем собирать mingw самому?

Источник

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

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

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

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

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 и относительной изоляции от всей остальной системы.

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, можно поставить из репозиториев.

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

Hello World

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

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

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

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

Источник

Сборка mingw в windows

Давайте разберемся, что такое MinGW, а что такое MSYS и для чего они нужны.

MinGW – сокращение от “Minimalist GNU for Windows”, по своей сути MinGW является небольшой и лаконичной средой разработки нативных приложений для семейства OS Microsoft Windows.

MinGW предоставляет полный набор Open Source инструментов для программирования, который подходит для разработки нативного Windows приложения, которое не будет зависеть от C-Runtime библиотек каких-либо третьих сторон.

MinGW поддерживает идею минимализма, поэтому он никогда не будет полностью поддерживать среду исполнения POSIX, для развертывания POSIX приложений на Windows, для их полной поддержки существует Cygwin. В первую очередь MinGW предназначен для использования разработчиками, которые привыкли работать с компилятором gcc.

MinGW включает в себя:

MSYS – сокращение от “Minimal SYStem”, это порт командной оболочки Bourne Shell (sh) для Windows. Он предлагается в качестве альтернативы “cmd.exe” от Microsoft’а. Оболочка хорошо подходит для портирования существующих приложений и библиотек, которые есть в *nix системах и включает в себя небольшой выбор портов инструментов Unix, облегчающих задачу портирования.

Комбинация MinGW и MSYS предоставляет разработчикам небольшую независимую среду, которая может быть легко загружена на съемные носители, не требуя добавления записей в файлы реестра.

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

И в итоге получаем исполнительный файл “GLUT-Req.exe”. Обратите внимание на:

Без установки этих переменных CMake не видит библиотеку GLUT.

Из названий переменных все должно быть понятно:

Каталог с исходниками можно оставить в чистом состоянии. Для этого следует перейти в сборочный каталог (в данном случае “build_project”) и разверенуть в него дерево исходного кода с последующей генерацией Makefile’ов. Пример:

В аргумент “build” необходимо прописать путь до каталога с исходным кодом, который нужно оставить чистым. После выполнения команды в каталоге “build_project/” создастся полная копия дерева проекта и в этом каталоге можно будет выполнять дальнейшую сборку.

1.4.2.4. Кросскомпиляция с помощью CMake.

В папке с проектом создаем файл с расширением “.cmake”, например, “Toolchain-eldk-ppc74xx.cmake”, с подобным содержимым:

И конфигурируем проект:

Если переменная “CMAKE_FIND_ROOT_PATH_MODE_PROGRAM” установлена в NEVER, то будут использоваться инструменты из недр вашей системы. Если она установлена в ONLY, то будут использованы инструменты из каталога “CMAKE_FIND_ROOT_PATH/bin”. В этом случае следует быть осторожным, так как из поля видимости CMake пропадают некоторые кросс-утилиты из состава binutils, например tuple-ar и tuple-ranlib. Решить эту поблему можно с помощью создания симлинков на эти инструменты. Симлинки следует расположить в директорию “CMAKE_FIND_ROOT_PATH/bin”. В противном случае, при сборке проекта может возникать следующая ошибка:

Подробнее можно прочесть тут: CMake Cross Compiling

1.4.3 Что почитать про CMake? (литература):

Источник

Картинка с сайта: uzverss.livejournal.com

Содержание:

1. Установка и настройка тулчейна MinGW/MSYS и дополнительного ПО

Давайте разберемся, что такое MinGW, а что такое MSYS и для чего они нужны.

• Порт GNU Compiler Collection (GCC), который включает в себя компиляторы таких языков, как: C, C++, ADA и Fortran.
• Порт GNU Binutils для Windows (as, ld, ar)
• Консольный установщик (mingw-get) для MinGW и MSYS
• Графический установщик (mingw-get-inst)

MSYS – сокращение от “Minimal SYStem”, это порт командной оболочки Bourne Shell (sh) для Windows. Он предлагается в качестве альтернативы “cmd.exe” от Microsoft’а. Оболочка хорошо подходит для портирования существующих приложений и библиотек, которые есть в *nix системах и включает в себя небольшой выбор портов инструментов Unix, облегчающих задачу портирования.

<< Перейти к содержанию

1.1. Устанавливаем MinGW, оболочку MSYS и настраиваем окружение

Картинка с сайта: uzverss.livejournal.com

Жмем “Next” и соглашаемся с лицензией, снова “Next”, и теперь выбираем путь для установки:

Картинка с сайта: uzverss.livejournal.com

Рекомендуется выбирать путь без пробелов, лучше всего устанавливать MinGW в корень диска, т.е в “C:\MinGW”. Я выбрал “C:\Qt\MinGW”, так удобнее будет подключить MinGW к IDE QtCreator. Если вы планируете дальше интегрировать свой тулчейн в какую-нибуть IDE, сделайте аналогично и нажмите “Next”. Необходимость наличия группы ярлыков в меню “Пуск” – по вашему желанию. Но можно не создавать (отметив галочкой “Don’t create a Start Menu folder) и нажать “Next”.

Выбираем следующие пакеты:

• C Compiler
• C++ Compiler
• MSYS Basic System
• MinGW Developer ToolKit

и жмем “Next”

Картинка с сайта: uzverss.livejournal.com

Картинка с сайта: uzverss.livejournal.com

mingw-get install msys-man
mingw-get install msys-wget
mingw-get install msys-zip
mingw-get install msys-unzip
mingw-get install msys-bzip2
mingw-get install msys-perl

mingw-get show | grep "Package: "

<< Перейти к содержанию

1.2. Настройка MinGW/MSYS: используем продвинутую консоль, вместо msys.bat

Возможно многим разработчикам стандартный шел, вызываемый по “msys.bat” покажется унылым и скучным:

Картинка с сайта: uzverss.livejournal.com

Картинка с сайта: uzverss.livejournal.com

<< Перейти к содержанию

1.3. Компиляция и установка утилиты pkg-config

export CFLAGS="-march=native"
cd /c/Qt/build/pkg-config-0.28
./configure --with-internal-glib --prefix=/mingw
make
make install
export -n CFLAGS

cat > /mingw/bin/pkg-config.sh << "EOF"
#!/bin/sh
if pkg-config "$@" > /dev/null 2>&1 ; then
res=true
else
res=false
fi
pkg-config "$@" | tr -d \\r && $res

EOF

chmod ugo+x /mingw/bin/pkg-config.sh && \
echo "PKG_CONFIG=/mingw/bin/pkg-config.sh" >> /etc/profile.local && \
echo "export PKG_CONFIG" >> /etc/profile.local

1.3.6. Когда вам понадобится альтернативное окружение, вы всегда можете подгрузить его командой:

source /etc/profile.local

<< Перейти к содержанию

1.4. Установка CMake, примеры использования

• Обычные Makefile, которые используются в системах Unix для сборки с помощью утилиты make;
• Файлы projects/workspaces (*.dsp/*.dsw) в системах Windows для сборки с помощью Microsoft Visual C++;
• Проекты XCode в Mac OS X.

Картинка с сайта: uzverss.livejournal.com

Картинка с сайта: uzverss.livejournal.com

1.4.1.5. При желании можно создать группу ярлыков в меню “Пуск”. Щелкаем “Установить”, ждем окончания установки и нажимаем “Готово”. Всё! CMake установлен.

project(GLUT-Req)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)

set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "C:/Qt/MinGW/lib")
set(CMAKE_INCLUDE_PATH ${CMAKE_INCLUDE_PATH} "C:/Qt/MinGW/include/GL;C:/Qt/MinGW/include")

##########################################################
find_package(OpenGL REQUIRED)
if(NOT OPENGL_FOUND)
    message(SEND_ERROR "Failed to find OpenGL")
    return()
else()
    include_directories(${OPENGL_INCLUDE_DIR})
endif()
##########################################################
find_package(GLUT REQUIRED)
if(NOT GLUT_FOUND)
    message(SEND_ERROR "Failed to find GLUT")
    return()
else()
    include_directories(${GLUT_INCLUDE_DIR})
endif()
##########################################################

link_libraries(${OPENGL_LIBRARY} ${GLUT_LIBRARIES})
add_executable(${PROJECT_NAME} ${SRC_LIST})

cmake -G "MSYS Makefiles"
make
make install

И в итоге получаем исполнительный файл “GLUT-Req.exe”. Обратите внимание на:

set(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "C:/Qt/MinGW/lib")
set(CMAKE_INCLUDE_PATH ${CMAKE_INCLUDE_PATH} "C:/Qt/MinGW/include/GL;C:/Qt/MinGW/include")

cmake -DCMAKE_INSTALL_PREFIX:PATH="/mingw" -DCMAKE_C_FLAGS:STRING="-march=i686" -DCMAKE_CPP_FLAGS:STRING="" -DCMAKE_CXX_FLAGS:STRING="" \
-DCMAKE_EXE_LINKER_FLAGS:STRING="-L/usr/local/lib -L/opt/local/lib" -DCMAKE_MODULE_LINKER_FLAGS:STRING="-L/usr/local/lib -L/opt/local/lib" \
-DCMAKE_SHARED_LINKER_FLAGS:STRING="-L/usr/local/lib -L/opt/local/lib" -G "MSYS Makefiles"

Из названий переменных все должно быть понятно:

-DCMAKE_INSTALL_PREFIX:PATH #- путь, куда будет устанавливаться программа после "make install".
-DCMAKE_C_FLAGS:STRING #- Установка флагов для файлов "*.c"
-DCMAKE_CPP_FLAGS:STRING / -DCMAKE_CXX_FLAGS:STRING #- Установка флагов для файлов "*.cpp" и "*.cxx" соответственно.
-DCMAKE_EXE_LINKER_FLAGS:STRING / -DCMAKE_MODULE_LINKER_FLAGS:STRING / -DCMAKE_SHARED_LINKER_FLAGS:STRING #- Установка файлов линковки.

Каталог с исходниками можно оставить в чистом состоянии. Для этого следует перейти в сборочный каталог (в данном случае “build_project”) и разверенуть в него дерево исходного кода с последующей генерацией Makefile’ов. Пример:

cd build_project/
cmake -G "MSYS Makefiles" --build ../project/src/

В аргумент “build” необходимо прописать путь до каталога с исходным кодом, который нужно оставить чистым. После выполнения команды в каталоге “build_project/” создастся полная копия дерева проекта и в этом каталоге можно будет выполнять дальнейшую сборку.

# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)

# specify the cross compiler
SET(CMAKE_C_COMPILER   /opt/eldk-2007-01-19/usr/bin/ppc_74xx-gcc)
SET(CMAKE_CXX_COMPILER /opt/eldk-2007-01-19/usr/bin/ppc_74xx-g++)

# where is the target environment 
SET(CMAKE_FIND_ROOT_PATH  /opt/eldk-2007-01-19/ppc_74xx /home/alex/eldk-ppc74xx-inst)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

И конфигурируем проект:

cmake -DCMAKE_TOOLCHAIN_FILE=Toolchain-eldk-ppc74xx.cmake

Если переменная “CMAKE_FIND_ROOT_PATH_MODE_PROGRAM” установлена в NEVER, то будут использоваться инструменты из недр вашей системы. Если она установлена в ONLY, то будут использованы инструменты из каталога “CMAKE_FIND_ROOT_PATH/bin”. В этом случае следует быть осторожным, так как из поля видимости CMake пропадают некоторые кросс-утилиты из состава binutils, например tuple-ar и tuple-ranlib. Решить эту поблему можно с помощью создания симлинков на эти инструменты. Симлинки следует расположить в директорию “CMAKE_FIND_ROOT_PATH/bin”. В противном случае, при сборке проекта может возникать следующая ошибка:

Error running link command: No such file or directory

Подробнее можно прочесть тут: CMake Cross Compiling

1. CMake Documentation [ENG]
2. Введение в CMake [RUS]
3. Используем Cmake для создания Makefile [RUS]

<< Перейти к содержанию

http://exlmoto.ru/mingw-development-environment/
http://www.linux.org.ru/forum/desktop/10819573
https://msys2.github.io/