Я исправил многие из моих ошибок и сейчас пытаюсь выяснить, могу ли я ссылаться на некоторые символы, используемые предварительно скомпилированными зависимостями, без перекомпиляции зависимостей в minGW.См. Изменения.
В настоящее время я работаю с сетевой библиотекой yojimbo (https://github.com/networkprotocol/yojimbo),, которая использует premake5 для конфигурации сборки, как зависимость от моего проекта. Часть C ++ моего проектаэто плагин Godot (https://godotengine.org/), и исполняемый файл автономного сервера. Я использую yojimbo как в плагине (который реализует игровой клиент), так и на сервере. Я хочу иметь возможность кросс-компиляции таргетинга моего плагинаWindows из моей среды разработки Linux, так как у меня нет выделенного компьютера с Windows, и я хочу, чтобы моя игра игралась в Windows. Это файл предварительного создания, используемый yojimbo: https://github.com/networkprotocol/yojimbo/blob/master/premake5.lua
Я собираюсь использоватьminGW для компиляции моего плагина в разделяемую библиотеку, но это означает, что мне также нужно иметь возможность компилировать yojimbo с помощью minGW. Мне не ясно, как указать исполняемый файл компилятора для premake, или вообще, какой лучший способ пересечьскомпилировать этот проект можно будет.
Я посмотрел на предварительно созданную вики Github, включая статью «Настройки сборки» (https://github.com/premake/premake-core/wiki/Build-Settings), и я не нашел настройки для цепочки инструментов компилятора.Я также попытался указать опцию --os = windows для файла premake yojimbo, но, похоже, он создает исполняемые файлы linux и статическую библиотеку, скомпилированную gcc, просто переименованную в program.exe и library.lib вместо program и library.а.Полная команда, которую я использовал, была premake5 --os=windows gmake, а затем make all.
Еще одна вещь, которую я пробовал, это генерирование Makefile с premake, затем сборка с CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ make all.Если бы я сгенерировал Makefile без --os=windows, компиляция не удалась бы, потому что заголовки для зависимостей yojimbo не были бы найдены (репозиторий предоставляет заголовки и двоичные файлы статической библиотеки для сборки окон).Если я сгенерировал его с помощью --os=windows, я получил бы эти ошибки (https://paste.debian.net/1087896/),, что, я думаю, может быть связано с тем, что компиляция под windows зависит от некоторых прагм VCC.
Как использовать premake / extension buildфайл конфигурации и т. д. для кросс-компиляции yojimbo с использованием mingw?
EDIT: ошибка pton была вызвана тем, что функция недоступна в minGW, поэтому я скопировал вставленный условный код из зависимости, чтобы определить эту функцию, который справился с этим делом. Я также «исправил» проблему с PRIu64, как в Почему PRIu64 не работает в этом коде? , определив __STDC_FORMAT_MACROS до того, как yojimbo включает <inttypes.h>. Теперь я получаюнекоторые ошибки компоновщика: https://paste.debian.net/1087906/
EDIT2: я обнаружил, что смог устранить некоторые ошибки компоновщика путем явного связывания в WS2_32 (winsockets), и я также связался с IPHLPAPI, поскольку он был указан в одном изигнорируемые прагмы. Я все еще получаю ошибки компоновщика о __GSHandlerCheck, __security_check_cookie и связанных с ними символах, однако. Проведя некоторое исследование, я обнаружил, что это было комбоПроблема n связана с тем, что minGW не предоставляет некоторые символы, которые предоставляются средой выполнения Visual C. Это одно из последних упоминаний, которые я нашел: https://reviews.llvm.org/D27296
Означает ли это, что мне потребуется перекомпилировать предоставленные зависимости с помощью minGW, чтобы избежать зависимости от MSVCRT, или что-то изменилось с 2016 года,чтобы я мог ссылаться на эти библиотеки?
EDIT3: На самом деле эта ссылка, на которую я ссылался, говорит о разных символах и, кстати, включает упоминания о символах, с которыми у меня проблемы.Вот более старый пост о символах: https://mingw -w64-public.narkive.com / BL8QrPyY / undefined-reference-to-gshandlercheck