运行在 cygwin 中编译的应用程序,无需安装 cygwin

发布于 2024-08-16 12:57:18 字数 88 浏览 2 评论 0原文

假设我有一个在 cygwin 下编译的应用程序,并且我想在不让用户安装 cygwin 的情况下分发该应用程序。打包可执行文件和 cygwin DLL 就足够了吗?

Let's say I have an application which I compiled under cygwin, and I want to distribute that application without having the user to install cygwin. Would it be enough to package the executable and the cygwin DLL?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

扛刀软妹 2024-08-23 12:57:18

事情已经改变了。 Cygwin 库现在采用 Lesser GPL (v3),这使得将它们与属于各种许可证(从 FOSS 到专有)的应用程序捆绑在一起成为可能。

阻碍的是 Cygwin 中的 POSIX 模拟从本机 Windows 应用程序的角度来看有点太远了。

这就是我的 Cygnal 项目的用武之地。Cygnal 代表 CYGwin Native Application Library:它是一个插件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 下,如果您 chdirD:\wherever 那么您当前的驱动器是 D 驱动器,路径为 /foo< /code> 或 \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 函数报告带有 CYGNAL 前缀的 sysname,而不是 CYGWIN。通过这种方式,您的程序可以知道它是在 Cygnal 而不是 Cygwin(或任何其他 POSIX 平台)上运行。因此,您可以进行任何必要的调整:例如,如果您的程序需要 /dev/null,在 Cygnal 上它可以查找 dev:/null

Things have changed. The Cygwin libraries are now under the Lesser GPL (v3), which makes it possible to bundle them with applications that fall under a wide range of licenses, from FOSS to proprietary.

What stands in the way is that the POSIX emulation in Cygwin takes things a little too far from the perspective of native Windows applications.

This is where my Cygnal project comes in. Cygnal stands for CYGwin Native Application Library: it is a drop-in compatible fork of Cygwin which changes, or in some cases simply re-configures, the behaviors of certain functionality in order to conform with native conventions of the Windows platform.

A basic "Hello, World" Cygwin program requires two libraries. A GCC run-time called cyggcc_s-1.dll and the Cygwin DLL cygwin1.dll. The Cygnal project provides a replacement for the latter. (A 32 bit build is available for download).

One glaring area of incompatibility between the Cygwin POSIX view of the world and Windows is path handling. The Cygwin view of the filesystem is through a fake / root directory, and its own internal "mount table" which provides spaces like /cygdrive, /proc and /dev. Cygnal does away with all that. Paths are Win32 paths. The current working directory behaves like the Windows current working directory. Drives are associated with current directories, and drive relative paths like D:foo.txt work under Cygnal. Under Cygnal, /dev and /proc are still available: they are accessed as the special prefixes dev:/ and proc:/. It is not permitted to chdir into these: that would not be native! Under Cygnal, if you chdir to D:\wherever then your current drive is the D drive, and the paths /foo or \foo refer to D:\foo. Cygwin's master POSIX root directory is gone.

Yet, with Cygnal, you can continue to use the POSIX functionality, making it possible to develop cross-platform programs that have less code that is switched based on platform, compared to maintaining a port using MinGW or Microsoft Visual C/C++.

For example: you can write a Win32 console application using VT100 codes and termios. The same code will run on Unixes. No need to use the Win32 console API on Windows and VT100/termios on a POSIX system.

Another example: for threading, you can just use POSIX threads. pthread_create to start a thread, pthread_mutex_lock to lock a mutex and so on. Your program doesn't need a portability abstraction for threads which translates to Win32 or POSIX; you just use the POSIX and that's it.

The uname function in Cygnal reports the sysname with a CYGNAL prefix rather than CYGWIN. By means of this, your program can tell that it's running on Cygnal rather than Cygwin (or any other POSIX platform). Thus you can make any necessary adjustments: for instance, if your program needs /dev/null, on Cygnal it can look for dev:/null instead.

七月上 2024-08-23 12:57:18

您的应用程序实际上需要 Cygwin 提供的 Posix 仿真吗?如果没有,您可以使用 -mno-cygwin 标志来编译它,它根本不依赖于 cygwin,而是一个本机 Windows 应用程序。通常,您只需要一个真正的 shell (bash) 来配置和构建应用程序,但实际上并不需要 Cygwin 的 Posix 功能。

另一种选择是 MSYS + MinGW,它是 Cygwin 的轻量级分支。这提供了一个默认生成本机 Windows 应用程序的编译环境。

第三种选择是使用 Cygwin 本身的 MinGW 编译器。它们应该可以通过普通的 Cygwin 包管理器获得。然后,您可以使用 MinGW 编译器配置项目进行交叉编译。

Does your application actually need any Cygwin provided Posix emulation? If not, you can compile it with the -mno-cygwin flag and it won't depend on cygwin at all, but will be a native Windows application. Often, you only need a real shell (bash) to configure and build your application, but you don't actually need the Posix functionality of Cygwin.

Another alternative is MSYS + MinGW, which is a light-weight fork of Cygwin. This provides a compilation environment which produces native Windows apps by default.

A third option would be to use the MinGW compilers from Cygwin itself. They should be available via the normal Cygwin package manager. Then you would configure the project for a cross-compile using the MinGW compilers.

も星光 2024-08-23 12:57:18

通常情况下,是的。请务必将 Cygwin DLL 安装在公共位置 (Windows\System32),当在同一台计算机上加载多个版本时,此 DLL 的行为会非常糟糕。

Normally, yes. Be sure to install the Cygwin DLL in a public location though (Windows\System32), this DLL behaves very badly when multiple versions of it are loaded on the same machine.

一个人练习一个人 2024-08-23 12:57:18

您可以尝试将所有内容编译为静态。这应该允许您在不需要库的情况下运行所有​​内容(因为它们已经在您的二进制文件中)。
但这也意味着如果 cygwin 需要不同或更新的 dll,它可能无法在所有平台上工作。

You could try to compile everything as static. That should allow you to run everything without the need of the the libs (since they are already in your binary).
But this will also mean that it might not work an all platforms if cygwin would need a different or newer dll.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文