homepage

Downloaded Python-3.2.2.tar
cd Python-3.2.2
./configure
make
....
Fail on:
--------------------
.....
ranlib libpython3.2m.a
make: *** No rule to make target `libpython3.2m.dll.a', needed by `python.exe'. Stop.
--------------------
libpython3.2m.a was built successfully:
--------------------
$ ls -l libpython3.2m.a
-rw-r--r--+ 1 hbille Domain Users 7182050 Jan 10 13:31 libpython3.2m.a
--------------------
I am not sure which part is incorrect. The name with or without "dll"

I am not sure building CPython with Cygwin is supported.

The README file implies support:
[⋮]
Build Instructions
------------------
On Unix, Linux, BSD, OSX, and Cygwin:
[⋮]

Got it to build. Unpack the Python (3.2.2) source package and apply this patch to get a package that builds on Cygwin (1.7.9), eg:
xz -d patch.xz && tar -xJf Python-3.2.2.tar.xz && patch -p0 -i patch
Changes:
(1) The Makefile, makesetup, and distutils.UnixCCompiler and distutils.command.build_ext modules set values for locating cygwin's python library that didn't agree or make sense during buildtime, so I revised them to agree and use build options that work.
(2) configuration and setup.py couldn't locate cygwin's ncurses headers, so I revised them to do that. I don't think I made that change as portable friendly as possible, so someone please check that and find a better way.
Your input is welcome.

Martin, any input?
Uncompressed patch attached. Plain text files are easier to review and devoid of security issues (unlike executables on Windows, PDFs if you’re using Adobe Reader, etc.).

The removal of testing for ncurses.h is incorrect: this should break the Linux build, where ncurses.h is indeed commonly located in /usr/include.
Not sure how to proceed here: if somebody would try to reproduce the problem, they would likely come up with a patch which is fairly different from the one you are proposing. 
So, Luis: are you interested in working out a complete and correct patch? If so, please start with generating one that is against the hg 3.2 branch (or perhaps even against the default branch). It's ok if you are not interested, in that case we'll need to wait for some other volunteer.

I offer the attached patch for consideration. AFAICT, only the Makefile.pre.in and build_ext.py changes are required. I included the makesetup change for completeness and to be consistent with the other changes.

Hi Jason,
if you look in default rule you will see the same, so this relict specific "else case" could be removed. Also in Lib/packaging/command/build_ext.py.

Is this still an issue on 3.3/3.4? Does the patch still work?

> Is this still an issue on 3.3/3.4?
I presume so.
> Does the patch still work?
I haven't tried it on 3.3 yet, so I don't know if it will apply cleanly.

Jason Tishler wrote:
> Jason Tishler added the comment:
>
>> Is this still an issue on 3.3/3.4?
> I presume so.
This build is broken since SOABI implementation.
>
>> Does the patch still work?
> I haven't tried it on 3.3 yet, so I don't know if it will apply cleanly.
Attached "0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch" for head.
This patch is part of split issue3871 into small independent changes.
Roumen

I have no objection to the patch. I can’t test it on cygwin (unless snakebite provides it, I’ll ask) but I can check that a linux build still works.

I can confirm that the last attached patch on this issue fixes this particular issue with building on Cygwin. There are other issues but this is definitely one of them.

New changeset 5b4c21436036 by Zachary Ware in branch 'default':
Issue #13756: Fix building extensions modules on Cygwin
https://hg.python.org/cpython/rev/5b4c21436036 

Fixed on 3.7, we can evaluate backporting later. With this committed, a build on Cygwin can succeed if you configure with --without-threads.
Thanks for the patch!

FWIW, even with this patch and --without-threads Python does *not* build successfully on Cygwin64 (which is all I'm really interested in personally), though it does succeed on 32-bit Cygwin. This has two related reasons:
1) The build of Python's bundled libffi does not work on 64-bit Cygwin for at least a few reasons that I won't go into here. There doesn't seem to be a ticket yet for that so I'll open one.
2) Using --with-system-ffi doesn't work for reasons I talked about in #2445, and also discussed a bit in #1706863 

Hmm, Cygwin64 is what I built on (successfully). _ctypes does not build, but that's due to not having any libffi available at all: the bundled copy is no longer included in 3.7, and I didn't install a system copy. I view ctypes support as a fairly low-priority item; we have much bigger issues to worry about first :). If trying to build _ctypes actually crashes your build, I think '--without-system-ffi' might be enough to get it to error out cleanly.

Okay, that would explain it then. I was building from an older branch (pre-3.7) that still has the bundled libffi.
FWIW with the fix from #2445, --with-system-ffi works (as does some trivial use of _ctypes though I haven't run all the tests). So if the bundled libffi is gone then I guess that's a moot point.
Thanks for getting a bunch of these fixes merged.

No problem. Feel free to nosy me on any Cygwin issues that you feel have consensus on the solution and a commit-ready patch implementing it. I can't guarantee when I'll have time to look at them, but I have finally gotten around to installing Cygwin and will get to them eventually :)