Dystrybucja programu skompilowanego z mingw g ++

Question

Załóżmy, że stworzyłem i skompilowałem prosty program przy użyciu mingw64 (kompilator g ++). Uruchomienie tego programu na komputerze i patrząc w Process Explorer dla co pliki DLL program korzysta znajdę (między innymi):

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

Są jedynymi, które znajdują się pod moim folderze instalacyjnym MinGW. Pozostałe używane biblioteki DLL znajdują się w C: \ Windows.

Pytanie 1: Czy biblioteki DLL MinGW są bibliotekami uruchomieniowymi MinGW C++ (że tak powiem)? Czy służą one temu samemu celowi, jak na przykład msvcrXXX.dll (XXX = wersja biblioteki uruchomieniowej Microsoft).

Pytanie 2: Jeśli chcę, aby uruchomić aplikację na innym komputerze, który nie posiada zainstalowanego MinGW, jest to wystarczające, aby objąć te pliki DLL wymienione powyżej (tj umieszczając je w tym samym folderze co moim pliku wykonywalnego) aby uruchomić go na drugim komputerze (zakładamy, że drugi komputer to także 64-bitowa maszyna Win). Jeśli tak, to znaczy, że zasadniczo wysyłamy środowisko wykonawcze MinGW C++ za pomocą naszego pliku wykonywalnego. Jeśli nie, dlaczego?

Dzięki.

Answer 1

libstdC++ 6.dll jest standardową biblioteką C++, tak jak powiedziałeś.

libwinpthread-1.dll służy do obsługi gwintowania C++ 11. MinGW-W64 ma dwa możliwe warianty gwintów: użyj rodzimych funkcji Windows takich jak CreateThread, ale rzeczy w C++ 11 takie jak std :: thread nie będą dostępne; lub włącz tę bibliotekę i użyj klas C++ 11 (też).
Pamiętaj, że aby przełączyć model gwintu, musisz przeinstalować MinGW. Po prostu usunięcie biblioteki DLL i nie używanie rzeczy w C++ 11 nie będzie działać, biblioteka DLL będzie jednak wymagana przy bieżącej instalacji.

libgcc_s_seh-1.dll to coś o obsłudze wyjątków C++.

Tak, to powinno być wystarczające, aby dostarczyć DLL zbyt
(lub użyć linkowania statycznego i dostarczyć tylko plik programu).

Answer 2

Istnieje kilka głównych wyzwań dystrybucją skompilowanego oprogramowania:

1. Kompilacja kodu dla wszystkich procesorów docelowych (Pamiętaj, jeśli chodzi do skompilowanego kodu, trzeba produkować oddzielne Downloads/dystrybucje dla każdego typu architektury zestawu instrukcji).

2. Zapewnienie, że kompilacje są odtwarzalne, składają się i mogą być łatwo skorelowane z konkretną wersją kodu (i wersjami zależności).

3. Zapewnienie, że dane wyjściowe kompilacji są samodzielne i zawierają wszystkie zależności w sobie (tak, aby nie było zależne od innych instalacji, które istnieją tylko w systemie).

4. Zapewnienie, że twój kod jest regularnie budowany i rozpowszechniany, a aktualizacje są rozpowszechniane automatycznie, dzięki czemu - w razie problemów związanych z bezpieczeństwem - możesz wypchnąć nowe poprawione wersje.

Dla wygody użytkowników i dla zwiększenia zasięgu dobrze jest, jeśli użytkownicy nie mają do dyspozycji gotowej wersji, którą mogą zainstalować. Zalecam jednak udostępnienie kodu źródłowego jako pierwszego kroku.

Większość tych wymagań jest dość nietrywialna i często wymagają automatyzacji nie tylko procesu tworzenia, ale także automatyzacji tworzenia/konfigurowania maszyn wirtualnych, w których ma się odbywać kompilacja. Istnieją jednak projekty open source, które mogą pomóc ... na przykład sprawdzić Gitian.

Pod względem punktu wypunktowania nr 3 kluczową sprawą jest tutaj użycie łącza statycznego ... podczas gdy powoduje to, że plik binarny, który rozpowszechniasz, jest znacznie większy (ponieważ jego zależności są teraz wypiekane na wyjściu), to także sprawia, że binarny izolowany z wersji bibliotek w systemie (unikając "piekła zależności").

Punkt # 4 jest bardzo trudny, ale na szczęście istnieją również narzędzia opensource do pomocy tutaj, jak również takie jak cloudup, który zapewnia sposób na dodanie możliwości automatycznej aktualizacji do dystrybucji aplikacji.

Answer 3

Świetne odpowiedzi już zamieszczone na temat tego, o czym należy pamiętać przy dystrybucji plików binarnych, ale chciałem po prostu zadzwonić. W przypadku skomplikowanych projektów, w których nie ma się pewności, które biblioteki dll muszą być dołączone do dystrybucji aplikacji, zrobiłem poręczny skrypt bashu dla dandysa (dla powłok MSYS2), który może dokładnie powiedzieć, jakie biblioteki dll musisz dołączyć. Opiera się na zależnościach walker binarny można uzyskać od 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 

zauważyć, że ten skrypt musiałby być nieznacznie zmodyfikowane do stosowania w regularnych Msys (The MSYS2_ARG_CONV_EXCL i dyrektyw cygpath w szczególności). Ten skrypt zakłada również, że twoje biblioteki dll są zlokalizowane w ścieżce zawierającej mingw.

Można nawet użyć tego skryptu do automatycznego skopiowania bibliotek DLL do katalogu kompilacji w ramach automatycznego systemu wdrażania. Mam nadzieję, że jest to przydatne dla kogoś tam!