運行的應用程序，在Cygwin中編譯，而無需安裝了cygwin

Question

比方說，我有我的cygwin下編譯的應用程序，我想分發應用程序，而無需用戶安裝cygwin。打包可執行文件和cygwin DLL足夠了嗎？

Answer 1

通常，是的。雖然（Windows \ System32）確保將Cygwin DLL安裝在公共位置，但是當它的多個版本加載到同一臺機器上時，此DLL的行爲非常糟糕。

Answer 2

你可以嘗試編譯所有靜態。這應該允許你運行一切，而不需要libs（因爲它們已經在你的二進制文件中）。 但是，這也意味着它可能無法正常工作的所有平臺上的cygwin是否需要不同的或較新的DLL。

Answer 3

您的應用程序是否真的需要任何Cygwin提供的Posix仿真程序？如果沒有，你可以使用-mno-cygwin標誌編譯它，它不會依賴於cygwin，而是一個本地Windows應用程序。通常，您只需要一個真正的shell（bash）來配置和構建應用程序，但實際上並不需要Cygwin的Posix功能。

另一種替代方案是MSYS + MinGW，它是Cygwin的輕量級叉子。這提供了一個默認生成本地Windows應用程序的編譯環境。

第三個選擇是從自身的Cygwin使用MinGW的編譯器。它們應該可以通過普通的Cygwin軟件包管理器來使用。然後，您將使用MinGW編譯器配置項目進行交叉編譯。

Answer 4

事情已經改變了。在Cygwin庫目前正在較寬鬆GPL（V3），這使得它能夠以落在下範圍廣泛的許可證，從FOSS到專有應用捆紮在一起。

什麼阻礙的方式是，在Cygwin中的POSIX模擬從本地Windows應用程序的角度看需要的東西有點過分。

這是我Cygnal項目進來Cygnal公司代表Cygwin的原生應用程序庫：這是一個簡易的Cygwin兼容叉而改變，或在某些情況下，只需重新可以配置，某些功能的行爲，以以符合Windows平臺的本地慣例。

一個基本的「Hello，World」Cygwin程序需要兩個庫。一個GCC運行時稱爲cyggcc_s-1.dll和Cygwin的DLL cygwin1.dll。 Cygnal項目爲後者提供了替代品。 （32位版本可供下載）。世界Cygwin的POSIX視圖和Windows之間的不兼容的

一個明顯的區域是路徑處理。文件系統的Cygwin的視圖是通過假/根目錄，它提供等/cygdrive，/proc和/dev空格其自身的內部「裝載表」。 Cygnal放棄了這一切。路徑是Win32路徑。當前工作目錄的行爲與Windows當前工作目錄類似。驅動器與當前目錄相關聯，驅動器相對路徑如D:foo.txt在Cygnal下工作。在Cygnal下，/dev和/proc仍可用：它們作爲特殊前綴dev:/和proc:/進行訪問。這是不允許chdir這些：這不會是本地的！在Cygnal下，如果chdir到D:\wherever那麼您當前的驅動器是D驅動器，而路徑/foo或\foo指的是D:\foo。Cygwin的主要POSIX根目錄不見了。

然而，使用Cygnal，您可以繼續使用POSIX功能，從而可以開發跨平臺程序，這些程序只需較少的代碼即可基於平臺進行切換，而使用MinGW或Microsoft Visual C/C++。

例如：你可以寫使用VT100代碼和termios一個Win32控制檯應用程序。相同的代碼將在Unix上運行。無需在Windows上使用Win32控制檯API，在POSIX系統上使用VT100/termios。

又如：穿線，你可以只使用POSIX線程。 pthread_create啓動線程，pthread_mutex_lock來鎖定互斥鎖等。對於轉換爲Win32或POSIX的線程，您的程序不需要可移植性抽象;你只需要使用POSIX就是這樣。

Cygnal中的uname函數報告sysname帶有CYGNAL前綴而不是CYGWIN。通過這種方式，您的程序可以知道它在Cygnal上運行，而不是在Cygwin（或任何其他POSIX平臺）上運行。因此，您可以進行必要的調整：例如，如果您的程序需要/dev/null，則可以使用Cygnal代替dev:/null。