Распространяйте программу, скомпилированную с помощью mingw g ++

Question

Предположим, что я создал и скомпилировал простую программу, используя компилятор mingw64 (g ++). Запуск этой программы на компьютере и глядя в Process Explorer для того, что библиотеки DLL программа использует я считаю (среди многих других):

libgcc_s_seh-1.dll 
libstdc++6.dll 
libwinpthread-1.dll 

Они являются единственными, которые находятся под моей папке установки MinGW. Остальные библиотеки DLL находятся в папке C: \ Windows.

Вопрос 1: Являются ли библиотеки MinGW библиотек времени выполнения MinGW C++ (так сказать)? Выполняют ли они те же цели, что, например, msvcrXXX.dll (XXX = версия библиотеки времени выполнения Microsoft).

Вопрос 2: Если я хочу, чтобы запустить приложение на другом компьютере, который не имеет MinGW установлен, достаточно ли включить эти библиотеки DLL файлы, перечисленные выше (т.е. размещая их в той же папке, как мой исполняемый файл) чтобы он запускался на другом компьютере (мы предполагаем, что другой компьютер также является 64-разрядной машиной Win). Если да, значит ли это, что мы в основном поставляем среду исполнения MinGW C++ с нашим исполняемым файлом. Если нет, то почему?

Спасибо.

Answer 1

libstdC++ 6.dll - это стандартная библиотека C++, как вы сказали.

libwinpthread-1.dll предназначен для поддержки потоков C++ 11. MinGW-W64 имеет два возможных варианта потока: либо используйте собственные функции Windows, такие как CreateThread, но C++ 11, например std :: thread, будет недоступен; или включить эту библиотеку и использовать классы C++ 11 (тоже).
Обратите внимание, что для переключения модели нити вам потребуется переустановить MinGW. Просто удалив DLL и не используя материал C++ 11 не получится, DLL потребуется, тем не менее, с вашей текущей установкой.

libgcc_s_seh-1.dll - это что-то о обработке исключений на языке C++.

Да, должно быть достаточно для доставки DLL слишком
(или использовать статические ссылки и доставлять только ваш файл программы).

Answer 2

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

1. Компиляция коды для всех целевых процессоров (помните, когда речь идет о для скомпилированного кода, необходимо произвести отдельные загрузки/распределения для каждого типа архитектуры набора инструкций).

2. Обеспечение того, что сборки воспроизводятся, состоят и могут быть легко сопоставлены с конкретной версией кода (и версиями зависимостей).

3. Обеспечение того, что вывод сборки является автономным и включает в себя все его зависимости внутри него (так что он не зависит от других установок, которые существуют на вашей системе).

4. Убедитесь, что ваш код создан и распространен регулярно, причем обновления распространяются автоматически, так что - в случае проблем с безопасностью - вы можете выталкивать новые исправленные версии.

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

Большинство из этих требований довольно нетривиально для удара и часто требуют автоматизации не только процесса сборки, но и автоматизации создания/конфигурации виртуальных машин, в которых должна выполняться сборка. Тем не менее, есть проекты с открытым исходным кодом, которые могут помочь ... например, проверить Gitian.

Что касается пункта № 3, ключевая вещь здесь - использовать статическую привязку ... в то время как это делает бинарный файл, который вы распространяете намного больше (поскольку его зависимости теперь испечены в результате), это также делает ваш бинарный, изолированный от версии библиотек в системе (избегая «аджания ад»).

Пункт №4 очень сложный, но, к счастью, здесь есть также инструменты с открытым исходным кодом, такие как cloudup, что дает возможность добавить возможности автоматического обновления для распространения вашего приложения.

Answer 3

Ответы на вопросы, которые следует учитывать при распространении двоичных файлов, но я просто хотел прослушивать. Для сложных проектов, где вы не совсем уверены, какие DLL должны быть включены для распространения вашего приложения, я сделал (для MSYS2-оболочек), который может рассказать вам, какие именно DLL-файлы вам нужно включить. Это зависит от зависимостей ходунков двоичных вы можете получить от here

#!/usr/bin/sh 

depends_bin="depends.exe" 
target="./build/main.exe" #Or wherever your binary is 
temp_file=$(mktemp) 
output="dll_list.txt" 

MSYS2_ARG_CONV_EXCL="*" `cygpath -w $depends_bin` /c /oc:`cygpath -w $temp_file` `cygpath -w $target` 
cat $temp_file | cut -d , -f 2 | grep mingw32 > $output 

rm $temp_file 

Обратите внимания, что этот скрипт необходимо будет слегка модифицирован для использования в обычных MSYS (The MSYS2_ARG_CONV_EXCL и директивах cygpath, в частности). Этот сценарий также предполагает, что ваши mllw dll находятся в пути, который содержит mingw.

Возможно, вы даже можете использовать этот скрипт, чтобы автоматически копировать соответствующие DLL-файлы в каталог сборки как часть системы автоматического развертывания. Надеюсь, что это полезно кому-то там!