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

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

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

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

Войдите в MinGW

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

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

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

root $ dnfinstall mingw64-gcc mingw64-gcc-g++ mingw64-…

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

root $ dnf установите mingw32-gcc mingw32-gcc-g++ mingw32-…

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

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

С make

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

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

• Должна быть возможность указать, какой компилятор C / C++ следует использовать (например, через CC)
• Должна быть возможность указывать флаги компоновщика (например, через LDLIBS)

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

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

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

# Для 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», но проблема с использованием этой переменной заключается в том, что при вызове компилятора содержимое переменной помещается перед именами объектов, например:

x86_64-w64-mingw32-gcc -Wall -Wextra -lmingw32 -lm -o «build/my-game.exe» build/mygame.o build/stuff.o build/fluff.o

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

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

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

user $ cmake-DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw64.cmake [args…]

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

user $ cmake-DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/toolchain-mingw32.cmake [args…]

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

root $ dnf install mingw64-SDL2 mingw64-SDL2_image mingw64-SDL2_mixer mingw64-SDL2_ttf

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

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

Каталоги в этом архиве содержат DLL-файлы (в bin/), заголовки (в include/) и файлы .a – проще говоря, все, что вам нужно, чтобы иметь возможность компилировать и связывать программу с Allegro, не компилируя саму Allegro. Теперь все, что осталось сделать, это скопировать эти файлы в MinGWroot – это /usr/x86_64-w64-mingw32/sys-root/mingw/ для 64-битных библиотек и /usr/i686-w64-mingw32/sys-root/mingw/ для 32-битных библиотек.

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

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

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

Библиотеки DLL

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

user$ objdump -x my-awesome-game.exe | grep ‘Имя DLL:’

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

Компиляция C++ кода с помощью g++

Для этого урока у вас должна быть установлена программа g++. g++ — производное имя от gcc. gcc — компилятор языка C. Имя gcc образовано от GNU C Compiler. GNU — операционная система, а также это набор свободного ПО, включая gcc и g++ (компиляторы C/C++).

Если вы используете Linux, то g++ уже установлен.

g++ для Windows

Есть пара вариантов, как установить g++ на Windows. Cygwin и MinGW32. MinGW имеет версию для архитектуры x86-64. И именно её мы и будем использовать. Скачайте MinGW-W64, установите, а затем найдите mingw в меню Пуск (MinGW-W64 -> Run Terminal), или зайдите в папку с программой в проводнике (нужно запускать файл mingw-w64.bat). Вы увидите командную строку Windows.

Работа с командной строкой Windows

Если вы никогда не использовали командную строку, то вот несколько полезных команд:

Имя диска с двоеточием — перейти на определённый диск. Например, я храню код на диске D, поэтому моей первой командой будет:

cd — изменить директорию (change directory). Эта команда переместит вас в нужную директорию. Я храню код для данных уроков в папке: d:\prog\cpp. Поэтому, после того как я выбрал диск D, я обычно ввожу следующую команду:

cd .. (две точки) переместит вас в папку выше.

Исходный код

Создайте файл hello_world.cpp в папке, где вы планируете хранить свой код. Откройте его в простом текстовом редакторе: Notepad/Gedit/Notepad++/Sublime. И вставьте следующий текст:

После выполнения данной команды, в текущей директории будут создан файл: a.out или a.exe. Чтобы запустить программу, введите имя файла в консоли и нажмите Ввод (Enter). В консоли вы увидите текст Hello World. После этого программа сразу завершится.

a.out — имя по умолчанию для скомпилированных файлов. Мы можем изменить его:

Выполнив последнюю команду, мы получим файл hello_world.exe. После этого в Windows скомпилированную программу можно выполнить следующей командой:

Компиляция (compilation) и связывание (linking)

Во время компиляции происходит два шага. Первый — компиляция файлов с исходным кодом. Результат этого шага: объектный код. Объектный код помещается в файлы с расширением .o. Следующий шаг — связывание (linking). Специальная программа — компоновщик (linker), берёт объектные файлы и «связывает» их вместе. Компоновщик необходим, когда есть больше одного файла с исходным кодом. Пока наши программы будут состоять из одного файла. Но в будущем нам понадобится компоновщик.

Заключение

Мы рассмотрели как компилируется C++ код с помощью компилятора g++. Теперь мы готовы к изучению C++. А начнём мы с разбора программы Hello World.

GNU Compiler Collection, первые шаги

Эта заметка призвана на простых примерах познакомить начинающего nix-разработчика с инструментами GNU, в частности с компилятором GCC.

С его помощью мы и создадим простейшую программу. По большому счету все, как обычно. Заводим специальную папку, в которой будет размещаться проект.
Создаем в ней файл с именем: hello.c
Открываем файл в любом текстовом редакторе и пишем простейший код:

#include
int main(void)
<
printf(«Hello world!»);
return(0);
>

Сохраняем файл и выполняем команду: gcc hello.c

В созданной нами папке появился новый файл — a.out, это название присваивается по умолчанию, если специально не задано другого.

Это и есть исполняемый файл. Попробуем его запустить, для этого в консоли набираем: ./a.out

И радуемся в связи с первой написанной программой в линуксе!

Идем далее. При запуске исполняемого файла, если мы укажем только его название, система будет искать его в каталогах /usr/bin и /usr/local/bin, и, естественно, не найдет. Первый из них предназначен для размещения стабильных версий программ, как правило, входящих в дистрибутив Linux. Второй – для программ, устанавливаемых самим пользователем (за стабильность которых никто не ручается). По умолчанию, при сборке программы, устанавливаются в каталог /usr/local/bin.

Флаги используемые при компиляции

Флаг -o используем чтобы указать определенное имя получаемому исполняемому файлу: gcc hello.c -o say_hello

Флаг -E используем чтобы посмотреть, что получается после работы препроцессора. Этот флаг останавливает выполнение программы, как раз на этапе обработки препроцессором. В результате получается файл исходного кода с включённым в него содержимым заголовочных файлов.
Выподняем/смотрим: gcc -E hello.c -o hello.cpp

Флаг -с используем для создания объектных файлов (аналог *.obj): gcc -c kalkul.c

Название получаемого файла такое же, но компилятор изменяет расширение .c на .o (но указать можно и вручную).

Флаг -x используем, если создаётся объектный файл из исходника, уже обработанного препроцессором (например такого, какой мы получили выше), мы должны обязательно указать явно, что компилируемый файл является файлом исходного кода, обработанный препроцессором, и имеющий теги препроцессора. В противном случае он будет обрабатываться, как обычный файл C++, без учёта тегов препроцессора, а значит связь с объявленными функциями не будет устанавливаться.

Файл C++, обработанный препроцессором обозначается cpp-output:
gcc -x cpp-output -c hello.cpp

Собирается проект следующим образом: gcc hello.o -o say_hello
Запускаем: ./say_hello

Для чего нужна вся эта возня с промежуточными этапами?
Программы редко состоят из одного файла. Как правило исходных файлов несколько, и они объединены в проект. И в некоторых исключительных случаях программу приходится компоновать из нескольких частей, написанных, возможно, на разных языках. В этом случае приходится запускать компиляторы разных языков, чтобы каждый получил объектный файл из своего исходника, а затем уже эти полученные объектные файлы компоновать в исполняемую программу.