build script is broken on Cygwin

[chungy]

This was reported in IRC by a user attempting to build Chocolate Doom on Windows, he ran into the following issues (and eventually gave up and installed MSVC...):

• The script complains about no compiler being found and instructing to install GCC. With the minimum required packages as listed on the wiki, the native Cygwin GCC is not installed, only mingw's. This was temporarily repaired by removing the check for gcc from the script
• The host triplet was not properly detected. This was worked around by adding --host=i686-pc-mingw32 to the ./configure line in the script.
• Even with the above, SDL_net eventually fails because its build system tries to call plain old GCC, which is the first issue all over again. This one should be fixable by creating a patch, but that's the point the user gave up and installed MSVC to build Chocolate Doom.

This is probably not too difficult to work in with a proper way. It is probably most useful that the build script checks for and uses one of these GCCs on Cygwin, in this order:

1. i686-pc-mingw32: this is the original mingw project's 32-bit compiler. We are presently preferring it because it builds executables/DLLs compatible with Windows NT 3/4 and 95/98/Me. The project is poorly maintained (they're lagging behind four major GCC versions); SDL2 won't run on these platforms at all, so we might consider abandoning this toolchain (and those OSes) once that port is complete.
2. i686-w64-mingw32: this is the mingw64 project's 32-bit compiler. Despite the name, it has no code relation to the original project and the name reflects the original goal of a 64-bit toolchain. It is maintained in upstream GCC itself and has good maintenance and doesn't lag in releases. The only downside is that this generates Windows DLLs and executables that can only run on Windows 2000 or newer (no Win9x or NT 3/4 support), even though SDL1 can run on the older platforms. It also introduces a couple new DLL dependences: libgcc_s_*.dll, the standard library, mingw32 uses the system msvcrt.dll instead; and libwinpthread.dll, a POSIX Threads implementation for Windows.
3. x86_64-w64-mingw32: likewise, the mingw64 project's 64-bit compiler, capable of producing executables that run on all 64-bit versions of Windows from XP and up. This should take the lowest precedence simply because 64-bit Windows builds are not particularly useful, especially being incapable of running on any 32-bit install, but it's still possible somebody might install only this toolchain with the intent of a 64-bit build. Just as the 32-bit compiler, the extra DLL dependencies are introduced.

The native Cygwin GCC is left from the list on purpose: Chocolate Doom's behavior with a Cygwin-native build is strange (for example, both POSIX and _WIN32 are defined) and while definitely usable, it works contrary to any expectations from the official native builds (using mingw). If someone is really seeking to do this, I'm OK with leaving them to do it manually.

Fixing the ./configure line should take the triplet detected by whichever the three toolchains was detected first. Otherwise a native Cygwin build will be attempted, which will either fail completely if the native GCC is not installed, or produce DLLs incompatible with linking to mingw EXEs.

[fabiangreffrath]

AFAIUI, the compiler tool chain should be decided by the host variable set in the ./configure script which is either explicitly passed by a --host parameter or "guessed" by config.{sub,guess}. Have you considered updating these two files? Have you run autoreconf -vif or any other means to bootstrap the source?

[fragglet]

Thanks for the really detailed bug report. I'm hoping to be able to get a new Windows install up and running soon so hopefully I'll be able to iron out some of the problems with the build script.