I was having an issue building extension with a fresh checkout of
revision 61699. distutils was using the UnixCCompiler. This is not able
to find thec correct libraries to link against. I made a few changes in
this patch:

* distutils now uses the CygwinCCompiler when building extensions on the
Cygwin platform
* CygwinCCompiler.static_lib_extension needed to be .lib.a instead of
just .a
* Added some files to the svn:ignore property on a handful of directories.

The patch contains lots of unrelated changes. Can you please provide a
clean patch and some doc updates? The rest looks fine to me.

As Christian suggested I removed the unrelated svn:ignore changes.

The following will also let environment variables be passed to the
CygwinCCompiler.

--- orig/sysconfig.py	2008-05-19 00:26:03.953125000 -0700
+++ copy/sysconfig.py	2008-05-19 00:14:51.609375000 -0700
@@ -145,7 +145,7 @@
     Mainly needed on Unix, so we can plug in the information that
     varies across Unices and is stored in Python's Makefile.
     """
-    if compiler.compiler_type == "unix":
+    if compiler.compiler_type in ("unix", "cygwin"):
         (cc, cxx, opt, cflags, ccshared, ldshared, so_ext) = \
             get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
                             'CCSHARED', 'LDSHARED', 'SO')

# I found this infomation via "svn blame"

According to issue403947, cygwin once used CygwinCCompiler, and problem
was there, swiched to UnixCCompier. (r19674)

If this issue is not solved yet, maybe it's not good to go back to
CygwinCCompiler. (maybe)

May be check for compiler.compiler_type (from sysconfig.py ) has to be
replaced with a check for descendant classes of UnixCCompiler, i.e. to
include mingw32 too ?

Also CygwinCCompiler __init__ has to be reviewed too. As example :
-------------
        # Hard-code GCC because that's what this is all about.
        # XXX optimization, warnings etc. should be customizable.
        self.set_executables(compiler='gcc -mcygwin -O -Wall',
        .....
-------------
May override in unexpected way settings from customize_compiler.

I thin that proposed modification in sysconfig.py with removing(or
replacing)  of self.set_executables from CygwinCCompiler __init__  will
help me for issue3871 (cross building python for mingw32 with distutils). 

As example I will remove a hack in the setup.py:
-----------------------
@@ -196,8 +196,26 @@
         if compiler is not None:
             (ccshared,cflags) =
sysconfig.get_config_vars('CCSHARED','CFLAGS')
             args['compiler_so'] = compiler + ' ' + ccshared + ' ' + cflags
+
+        # FIXME: Is next correct ?
+        # To link modules we need LDSHARED passed to setup.py otherwise
+        # distutils will use linker from build system if cross-compiling.
+        linker_so = os.environ.get('LDSHARED')
+        if linker_so is not None:
+            args['linker_so'] = linker_so
+
         self.compiler.set_executables(**args)
-----------------------
Thanks to Hirokazu who point me, in an another thread, that cygwin build
don't use CygwinCCompiler.

P.S. : about: static_lib_extension = ".dll.a" - it is suffix for import
library  and "unixccompiler.py.diff" patch from issue1706863 propose 
dylib_lib_extension = ".dll.a" .

I forgot  an another issue in CygwinCCompiler __init__:
if gcc isn't version "2.91.57" then method will set dll_libraries to
result of get_msvcr(), but the result may be is None. In this case link
method fail on the line libraries.extend(self.dll_libraries).

I don't think the patch, cygwin-smaller.diff, is correct. The value of 
static_lib_extension needs to remain ".a". Otherwise, shared 
extensions attempting to build against a library that only offers a 
static version will fail to link.

AFAICT, Cygwin needs a concept that is not currently supported by 
distutils -- the ability to specify a shared library *link* extension 
(i.e., ".dll.a") which is different from the shared library extension 
(i.e., ".dll"). On Unix they are the same (e.g., ".so"), but on Cygwin 
they are different because of how Windows handles DLLs -- import 
library versus DLL.