假设我有一个在 cygwin 下编译的应用程序，我想分发该应用程序，而无需用户安装 cygwin。打包可执行文件和cygwin DLL就够了吗？
【问题讨论】：
标签： cygwin
情况发生了变化。 Cygwin 库现在在 Lesser GPL (v3) 下，这使得可以将它们与属于广泛许可（从 FOSS 到专有）的应用程序捆绑在一起。
阻碍的是 Cygwin 中的 POSIX 仿真与原生 Windows 应用程序的视角相差甚远。
这就是我的Cygnal 项目的用武之地。Cygnal 代表 CYGwin 本地应用程序库：它是 Cygwin 的一个插入式兼容分支，它改变，或者在某些情况下只是重新配置，某些功能的行为为了符合 Windows 平台的本机约定。
一个基本的“Hello, World” Cygwin 程序需要两个库。一个名为 cyggcc_s-1.dll 的 GCC 运行时和 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。
【讨论】：
您的应用程序是否真的需要任何 Cygwin 提供的 Posix 仿真？如果没有，您可以使用 -mno-cygwin 标志编译它，它根本不依赖于 cygwin，而是一个本机 Windows 应用程序。通常，您只需要一个真正的 shell (bash) 来配置和构建您的应用程序，但实际上并不需要 Cygwin 的 Posix 功能。
另一种选择是MSYS + MinGW，它是 Cygwin 的轻量级分支。这提供了一个编译环境，默认生成原生 Windows 应用程序。
第三种选择是使用 Cygwin 本身的 MinGW 编译器。它们应该可以通过普通的 Cygwin 包管理器获得。然后，您将使用 MinGW 编译器配置项目以进行交叉编译。
【讨论】：
通常，是的。请务必将 Cygwin DLL 安装在公共位置（Windows\System32），当在同一台机器上加载多个版本时，此 DLL 的行为会非常糟糕。
【讨论】：
您可以尝试将所有内容编译为静态。这应该允许您在不需要库的情况下运行所有内容（因为它们已经在您的二进制文件中）。 但这也意味着如果 cygwin 需要不同或更新的 dll，它可能无法在所有平台上运行。
【讨论】：