Uruchamianie aplikacji skompilowanej w cygwin, bez zainstalowanego cygwin

Question

Załóżmy, że mam aplikację, którą skompilowałem pod cygwin, i chcę ją rozpowszechnić bez konieczności instalowania cygwin. Czy wystarczy spakować plik wykonywalny i bibliotekę DLL cygwin?

Answer 1

Normalnie tak. Pamiętaj jednak, aby zainstalować bibliotekę DLL Cygwin w publicznej lokalizacji (Windows \ System32), ta biblioteka DLL zachowuje się bardzo źle, gdy wiele jej wersji jest ładowanych na tym samym komputerze.

Answer 2

Możesz spróbować skompilować wszystko jako statyczne. To powinno pozwolić ci uruchomić wszystko bez potrzeby bibliotek (ponieważ są już w twoim binarnym). Ale to również oznacza, że ​​może nie działać na wszystkich platformach, jeśli cygwin będzie potrzebował innej lub nowszej biblioteki dll.

Answer 3

Czy twoja aplikacja rzeczywiście potrzebuje jakiejś emulacji Posixa pod Cygwin? Jeśli nie, możesz skompilować go z flagą -mno-cygwin i nie będzie on w ogóle zależał od cygwin, ale będzie natywną aplikacją Windows. Często potrzebna jest tylko prawdziwa powłoka (bash), aby skonfigurować i zbudować aplikację, ale w rzeczywistości nie potrzebujesz funkcji Posix Cygwin.

Kolejną alternatywą jest MSYS + MinGW, która jest lekkim widelcem Cygwin. Zapewnia to środowisko kompilacji, które domyślnie tworzy rodzime aplikacje systemu Windows.

Trzecią opcją byłoby użycie kompilatorów MinGW z samego Cygwin. Powinny być dostępne za pośrednictwem normalnego menedżera pakietów Cygwin. Następnie należy skonfigurować projekt do cross-kompilacji przy użyciu kompilatorów MinGW.

Answer 4

Rzeczy się zmieniły. Biblioteki Cygwin są teraz objęte mniejszą GPL (v3), co umożliwia ich łączenie z aplikacjami, które wchodzą w zakres szerokiej gamy licencji, od FOSS do zastrzeżonych.

Co stoi na przeszkodzie temu, że emulacja POSIX w Cygwin nieco odbiega od perspektywy rodzimych aplikacji Windows.

Tutaj właśnie pojawia się mój projekt Cygnal. Cygnal to skrót od CYGwin Native Application Library: jest to kompatybilny widżet Cygwin, który zmienia, lub w niektórych przypadkach po prostu zmienia konfigurację, zachowania pewnych funkcji w kolejności aby dostosować się do natywnych konwencji platformy Windows.

Podstawowy program "Hello, World" Cygwin wymaga dwóch bibliotek. Czas działania GCC o nazwie cyggcc_s-1.dll i Cygwin DLL cygwin1.dll. Projekt Cygnal zapewnia zastąpienie tego ostatniego. (Kompilacja 32-bitowa jest dostępna do pobrania).

Jednym z jaskrawych obszarów niekompatybilności między widokiem Cygwina POSIX na świecie a systemem Windows jest obsługa ścieżek. Widok systemu plików Cygwin odbywa się poprzez fałszywy katalog główny / i jego własny wewnętrzny "stół montażowy", który udostępnia przestrzenie takie jak: /cygdrive,i /dev. Cygnal sobie z tym nie radzi. Ścieżki to ścieżki Win32. Bieżący katalog roboczy zachowuje się jak bieżący katalog roboczy systemu Windows. Dyski są powiązane z bieżącymi katalogami i napędzają ścieżki względne, takie jak D:foo.txt, działające pod Cygnalem. Pod Cygnalem, /dev i /proc są nadal dostępne: są dostępne jako specjalne prefiksy dev:/ i proc:/. Niedozwolone jest w tym: chdir: to nie byłoby natywne! Pod Cygnalem, jeśli jesteś chdir do D:\wherever, twój bieżący dysk to dysk D, a ścieżki /foo lub \foo odnoszą się do D:\foo.Główny katalog POSIX Cygwin już nie istnieje.

Jednak dzięki oprogramowaniu Cygnal można nadal korzystać z funkcjonalności POSIX, umożliwiając tworzenie programów wieloplatformowych, które mają mniej kodu, który jest przełączany w zależności od platformy, w porównaniu do utrzymywania portu przy użyciu MinGW lub Microsoft Visual C/C++.

Na przykład: można napisać aplikację konsoli systemu Win32 za pomocą kodów VT100 i termios. Ten sam kod będzie działał na Uniksach. Nie ma potrzeby korzystania z interfejsu API konsoli Win32 w systemie Windows i VT100/termios w systemie POSIX.

Kolejny przykład: do wątkowania można użyć wątków POSIX. pthread_create, aby rozpocząć wątek, pthread_mutex_lock, aby zablokować muteks i tak dalej. Twój program nie potrzebuje abstrakcji przenośności dla wątków przekładających się na Win32 lub POSIX; po prostu korzystasz z POSIX i to wszystko.

Funkcja uname w Cygnal zgłasza sysname z prefiksem CYGNAL zamiast CYGWIN. Dzięki temu Twój program może powiedzieć, że działa na Cygnalu, a nie na Cygwin (lub na dowolnej innej platformie POSIX). W ten sposób możesz dokonać niezbędnych poprawek: na przykład, jeśli twój program potrzebuje /dev/null, na Cygnalu może on zamiast tego szukać dev:/null.