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

Язык C

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

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

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

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

user $ cmake —build ./

Если вам кажется, что ваш дистрибутив не предоставляет готовый файл 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. Если вы загрузите один из них (выберите тот, который подходит для вашей цели кросс-компиляции) и распакуете архив, вы увидите такую структуру каталогов:

$ ls allegro-5.2.5.0/
bin/
include/
lib/

Каталоги в этом архиве содержат 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, которая отлично подходит именно для этой цели.

Оцените статью
Образовательный портал WELCOME4U.RU
Добавить комментарий

Adblock
detector