为什么GCC-Windows依赖于cygwin？
我不是 C++ 开发人员，但我一直对编译器感兴趣，并且对修补一些 GCC 的东西（特别是 LLVM）感兴趣。
在 Windows 上，GCC 需要 POSIX 仿真层（cygwin 或 MinGW）才能正确运行。
这是为什么？
我使用许多其他软件，用 C++ 编写并针对不同平台（Subversion、Firefox、Apache、MySQL）进行交叉编译，并且它们都不需要 cygwin 或 MinGW。
我对 C++ 最佳实践编程的理解是，您可以合理地编写与平台无关的代码，并在编译过程中处理所有差异。
那么与海湾合作委员会有什么关系呢？ 为什么它不能在 Windows 上本地运行？
编辑：
好的，到目前为止的两个回复基本上说，“GCC 使用 posix 层，因为它使用 posix 标头”。
但这并不能真正回答问题。
假设我已经为我最喜欢的标准库提供了一组标头。 为什么我仍然需要 posix 标头？
GCC 是否需要 cygwin/mingw 才能真正运行？
或者它只需要标头和库的模拟层？ 如果是这样，为什么我不能给它一个包含所需资源的“lib”目录？
再次编辑：
好的，我会再次尝试澄清问题...
我还用 D 编程语言。 官方编译器名为“dmd”，并且有适用于 Windows 和 Linux 的官方编译器二进制文件。
Windows 版本不需要任何类型的 POSIX 模拟。 Linux 版本不需要任何类型的 Win32 模拟。 如果编译器对其环境有假设，它就会很好地隐藏这些假设。
当然，我必须告诉编译器在哪里可以找到标准库以及在哪里可以找到要静态或动态链接的库。
相比之下，GCC 坚持假装它在 posix 环境中运行，并且它要求 ME 通过设置模拟层来适应这些假设。
但 GCC 内部究竟依赖于该层的是什么？ 它是否只是寻找 stdlib 标头，并且假设它会在“/usr/lib”中找到这些标头？
如果是这样的话，我难道不应该告诉它在“C:/gcc/lib”中查找这些头文件吗？
或者 GCC 本身是否依赖 POSIX 库来访问文件系统（以及执行其他低级操作）？ 如果是这样的话，那么我想知道为什么他们不只是静态链接到他们最喜欢的 Windows POSIX 库。 当用户可以将这些依赖项直接构建到应用程序中时，为什么要求用户设置依赖项？
I'm not a C++ developer, but I've always been interested in compilers, and I'm interested in tinkering with some of the GCC stuff (particularly LLVM).
On Windows, GCC requires a POSIX-emulation layer (cygwin or MinGW) to run correctly.
Why is that?
I use lots of other software, written in C++ and cross-compiled for different platforms (Subversion, Firefox, Apache, MySQL), and none of them require cygwin or MinGW.
My understanding about C++ best-practice programming is that you can write reasonably platform-neutral code and deal with all the differences during the compilation process.
So what's the deal with GCC? Why can't it run natively on Windows?
EDIT:
Okay, the two replies so far say, basically, "GCC uses the posix layer because it uses the posix headers".
But that doesn't really answer the question.
Let's say I already have a set of headers for my favorite standard library. Why would I still need the posix headers?
Does GCC require cygwin/mingw to actually RUN?
Or does it only need the emulation layer for headers and libraries? If so, why can't I just give it a "lib" directory with the required resources?
EDIT AGAIN:
Okay, I'll try again to clarify the question...
I also write code in the D Programming Language. The official compiler is named "dmd" and there are official compiler binaries for both Windows and linux.
The Windows version doesn't require any kind of POSIX emulation. And the Linux version doesn't require any kind of Win32 emulation. If the compiler has assumptions about its environment, it hides those assumptions pretty well.
Of course, I have to tell the compiler where to find the standard library and where to find libraries to statically or dynamically link against.
GCC, by contrast, insists on pretending it's operating within a posix environment, and it asks ME to humor those assumptions by setting up an emulation layer.
But what, exactly, within GCC relies on that layer? Is it just looking for stdlib headers, and it assumes it'll find those headers within "/usr/lib"?
If that's the case, shouldn't I just be able to tell it to look in "C:/gcc/lib" to find those header files?
Or does GCC itself rely on the POSIX libraries to access the file system (and to do other low-level stuff)? If that's the case, then I wonder why they don't just statically link with their favorite windows POSIX libraries. Why require the user to set up the dependencies, when they could build those dependencies right into the application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
实际上，问题前提是错误的： MinGW GCC 确实NOT需要Cygwin。
您会发现您根本不需要 Cygwin。 它在 Windows（至少 32 位）上本地运行。 工具链和生成的二进制文件都独立于 Cygwin。
Cygwin 中可用的 MinGW 编译器有所不同：它们构建在 Cygwin 平台上，用于生成不依赖于 Cygwin 运行时的代码。 在这种情况下，编译器本身确实依赖于 Cygwin。 但那是因为您是从 Cygwin 安装它们的。
Actually, the question premise is wrong: MinGW GCC does NOT require Cygwin.
You will see you don't need Cygwin at all. It runs natively on Windows (32-bit, at least). Both the toolchain and the produced binaries are independent of Cygwin.
The MinGW compilers available in Cygwin are different: they are built on the Cygwin platform, to generate code which does not depend on the Cygwin runtime. The compilers themselves do depend on Cygwin in that case. But that's because you installed them from Cygwin.
Cygwin 版本的 GCC 需要 Cygwin 要安装，用于它编译的程序。
MinGW 版本编译后不需要任何东西，除了 Windows 的工作副本。
您无法真正将 Cygwin 环境和 MinGW 编译器混合在一起，因为 Cygwin 更改了预编译库的路径。
如果您需要 bash 风格的 shell，但不想使用 Cygwin，我会推荐 MSYS 。
Cygwin 与 MinGW 的对比
复制自 MinGW Wiki
The Cygwin version of GCC requires Cygwin to be installed, for programs it compiles.
The MinGW version does not require anything after compiling, other than a working copy of Windows.
You can't really mix the Cygwin environment, and the MinGW compilers together, because Cygwin changes the paths of the precompiled libraries.
If you need a bash style shell, but don't want to use Cygwin, I would recommend MSYS.
Cygwin in contrast to MinGW
copied from MinGW Wiki
我尝试让我的程序在 Windows 下表现得像一个良好的 Windows 公民，在 Linux 下表现得像一个良好的 Linux 公民。
I try to make my programs under Windows behave like a good Windows citizen, and under Linux like a good Linux citizen.
POSIX（可移植操作系统接口）“是一个不断发展、不断发展的文档，由 IEEE 制定并由 ANSI 和 ISO 标准化。POSIX 的目标是应用程序源代码的可移植性”[1]。
实际上，目标被定义为能够编写一个源实现并使其在不同的（符合 POSIX 标准的）系统上运行，而只需重新编译。
GCC 是一个能够实现这一承诺的编译器，因此，它需要一层代码来使机器“达到”POSIX 标准。
这就是你问题答案的核心。
为了帮助您理解我的意思，我将向您提供这个练习：
我想你会发现编写只使用在任何 UNIX 或 LINUX 系统上编译的本机 WIN32 API 的代码是非常困难的，
编写使用 POSIX API 的代码只会稍微容易一些 - 就像在任何 LINUX 机器上一样- 并让它在 Windows 下编译（DevStudio2005 现在有数量惊人的 POSIX 兼容标头......您可能能够接近）。
从上面获取 LINUX 程序，现在在 Cygwin 或 MinGW 下运行的 GCC 下编译它。 我敢打赌它会编译并运行。
GCC 是如何施展这一魔法的呢？ Cygwin 或 MinGW 提供的 POSIX 标头及其底层实现。
GCC 在 Windows 下对 Cygwin/MinGW 的依赖现在更有意义吗？
POSIX (Portable Operating System Interface) "is an evolving, growing document that is being produced by IEEE and standardized by ANSI and ISO. The goal of POSIX is the source-code portability of application" [1].
In practical terms, the goal is defined as the ability to write one source implementation and have it run on different (POSIX-compliant) systems with only recompilation.
GCC is a compiler capable of delivering that promise and as such, it needs a layer of code that brings a machine "up to" POSIX standards.
That is the core of the answer to your question.
To help see what I mean, I'll offer you this exercise:
I think you will find that it is very difficult to write code that uses only the native WIN32 API that compiles on any UNIX or LINUX system
It will be only slightly less difficult to write code that uses POSIX API - as you can on any LINUX box - and have it compile under Windows (DevStudio2005 has a surprising number of POSIX-compliant headers now...you might be able to get close).
Take you LINUX program from above and now compile it under GCC running under Cygwin or MinGW. I'll bet it compiles and runs.
How did GCC perform that bit of magic? The POSIX headers and implementations underlying them provided by Cygwin or MinGW.
Does GCC's reliance on Cygwin/MinGW under Windows make more sense now?
Windows 不提供标准 POSIX 库，因此 cygwin 提供了一个 (cygwin1.dll)。 cygwin 附带的 gcc 软件包使用它。
另一方面，mingw 不一定提供 POSIX 层。 例如，我使用的 mingw 安装甚至没有 pthread 库。
如果我需要它，我就必须安装它。 Mingw-gcc 生成 Win32 本机代码（实际上依赖于 MSVCRT.DLL）。
编辑：阅读您的编辑我不再确定您是否在问为什么 gcc 本身需要 mingw/cygwin 库，或者在 Win 上使用 gcc 编译的程序是否需要这些库
Windows does not offer a standard POSIX library so cygwin provides one (cygwin1.dll). The gcc packages that comes with cygwin uses it.
mingw, on the other hand, does not necessarely provide a POSIX layer. The mingw installation that I use, for example, does not even have a pthread library.
Should I need it I would have to install it. Mingw-gcc produces Win32 native code (and in fact relies on MSVCRT.DLL).
EDIT: reading your edit I'm no longer sure if you're asking why gcc itself needs mingw/cygwin libraries or if the programs compiled with gcc on Win require those libraries
为什么？ 因为当 GCC 创建时，Windows 32 位甚至还没有退出
...正确 --- 它是为 UNIX/Posix 操作系统开发的。 后来被移植到windows上。
Windows 不是 POSIX 兼容系统。 它甚至不提供非常基本的功能。 尝试在Windows编译器下找到
readdir或stat？ 这是非常基本的功能，您需要编写编译器！需要明确的是，GCC 编译的程序通常只需要一个 mingw32.dll 来添加缺少的功能即可运行。
那么...你问为什么 GCC 需要一些 POSIX 层？ 因为Windows操作系统不是POSIX操作系统。
Why? Because when GCC was created, Windows 32 bit even hadn't exits...
To be more correct --- it was developed for UNIX/Posix OS. Later it was ported to windows.
Windows is not POSIX compient system. It even does not provide very basic functionality. Try to find
readdirorstatunder Windows compiler? And this is so extreamly basic functionality that you need to write compiler!Just to be clear, GCC compiled programs usually required only one mingw32.dll to add missing functionality to be able to run.
So... You ask why GCC requires some POSIX layer? Because Windows OS is not POSIX operating system.
请注意，LLVM 和 GCC 不相关。 LLVM 很大程度上是 Chris Lattner 所做的研究的结果 (http://llvm.org/developers.cgi) 关于现代优化。 他的论文可在 http://llvm.org 上找到。 如今，它得到了苹果公司的大力赞助。 GCC 的 C/C++/Obj-C 前端用于 llvm-gcc，它发出 LLVM 机器代码（在 llvm 中进行大量优化后，最终生成可执行文件）； llvm-gcc 是一种将一些现成的 C/C++/Obj-C 前端耦合到 LLVM 的 hack。
无论如何请注意，LLVM 团队还构建了一个自己的、完整的 C/C++/Obj-C 编译器，称为 clang。 它的 C 实现已接近完成，C++ 支持越来越好，但不知道 Obj-C。
因此，如果有人说“编译器 llvm”，他实际上意味着 llvm-gcc 或 clang。 LLVM 本身只是低级虚拟机，只有少量静态单赋值形式的指令（大约 32 条指令，公平地说），但语法树上传递了大量的优化。
Note that LLVM and GCC are not related. LLVM is largely the result of the research done by Chris Lattner (http://llvm.org/developers.cgi) about modern optimization. His papers are available on http://llvm.org. Nowadays, it is heavily sponsored by Apple. GCC's C/C++/Obj-C frontend is used for llvm-gcc, which emits LLVM machine code (and after a ton of optimizations in llvm, a final executable comes out); llvm-gcc is a kind of hack to couple some ready C/C++/Obj-C-frontend to LLVM.
Note anyways that the LLVM crew also builds an own, complete C/C++/Obj-C compiler, called clang. It's C implementation is near complete, C++ support is getting better and better, dunno about Obj-C though.
So, if someone says "compiler llvm", he really either means llvm-gcc, or clang. LLVM itself is just the Low Level Virtual Machine, with only a handful of instructions in Static Single Assignment form (approx. 32 instructions, afair), but a megaton of optimization passes upon thy syntax tree.
为不同平台编译的大部分软件都是在 MinGW 中编译的。 与 gcc 的唯一区别是它本身是一个编译器，这意味着它需要通常与程序一起编译的所有标头，并且通常不需要运行生成的程序。
Much of that software that is compiled for different platforms is compiled... in MinGW. The only difference with gcc is that it is a compiler itself, which means it needs all the headers that normally get compiled in with the program, and normally which one does not need to run the resulting program.
因为 GCC 的人们非常讨厌 Windows（有一天读到 Stallman）。 因此，当将 GCC 移植到 Windows 时，他们尽力假装它只是另一个 Unix。
他们可能不想花时间从代码中删除 POSIX 依赖项。
Because the people behing GCC hate Windows with a passion (read Stallman some day). So when porting GCC to Windows, they do their best to pretend it's just another Unix.
That, and they probably don't want to spend time on removing POSIX dependencies from the code.
gcc 的 MinGW-w64 端口为 32 位和 64 位 Windows 创建本机代码，无需任何其他依赖项。
例如，请参见 http://mstenberg.com/blog/2010/ 06/13/gcc-for-windows/ 快速入门指南。
The MinGW-w64 port of gcc creates native code for 32- and 64-bit Windows without any additional dependencies.
See for example http://mstenberg.com/blog/2010/06/13/gcc-for-windows/ for a quick getting-started guide.
如果您不想支持 pthreads 或 OpenMP，则在构建 gcc 时可以选择指定 posix 之外的启用线程选项。 不用说，这些都没有经过充分的测试。 有一些针对 Windows 线程的 OpenMP 的第三方闭源支持，但其与 gcc 的使用似乎违反了许可证。
由于 Windows pthreads 库是 Windows 线程功能的更高级别接口，因此当它性能不佳或遇到 Microsoft 拒绝亲和性支持时，也许并不奇怪。
直到最近，Microsoft 才开始在 Windows 上容忍 gcc。 曾经有一段时间，他们实际上表示不会处理 gcc 用户报告的错误，即使这些错误可以使用专门的 Microsoft 工具来重现。
You have an option when building gcc to specify enable-threads options other than posix, if you don't want to support pthreads or OpenMP. Needless to say, those aren't as well tested. There is some 3rd party closed source support for OpenMP with Windows threads, but its use with gcc appears to violate the license.
As the Windows pthreads library is a higher level interface to Windows threads functionality, it's perhaps not surprising when it doesn't perform as well or encounters Microsoft's rejection of affinity support.
Only recently has Microsoft begun to tolerate gcc on Windows. There was a time when they actually said they would not work on bugs reported by gcc users, even if they could be reproduced with exclusively Microsoft tools.