Why does GCC-Windows depend on cygwin?

Question

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,

Answer 1

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 readdir or stat under 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.

Answer 2

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.

Answer 3

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.

Answer 4

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:

• Write a program with no OS-specific #ifdefs that takes as input from the user some directory path and writes to stdout a listing of its contents (one level).

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?

1. POSIX.4: Programming for the Real World, Bill O. Gallmeister, O'Reilly & Associates, Inc., pg 2

Answer 5

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.