Using Cygwin 1.7, there are build failures for both _curses, _curses_panel, and _io. 

The curses failures are because symlinking /usr/include/{n}curses.h from /usr/include/{n}curses.h was removed in recent versions [0], so I added "-I/usr/include/ncurses" to the BASECFLAGS for cygwin. Not knowing the ins and outs of gcc/configure/make, I doubt the patch (ncurses_fix.diff) is correct or complete. It works on my machine so at least it's a starting point (maybe?).



_io gets the following warning and then later failure on gcc 4.3.4:
/cygdrive/c/Users/bcurtin/cygwin-python/release27-maint/Modules/_io/_iomodule.c:172: warning: ‘PyExc_BlockingIOError’ redeclared without dllimport attribute: previous dllimport ignored
...
build/temp.cygwin-1.7.5-i686-2.7/cygdrive/c/Users/bcurtin/cygwin-python/release27-maint/Modules/_io/bufferedio.o: In function `_buffered_check_blocking_error': /cygdrive/c/Users/bcurtin/cygwin-python/release27-maint/Modules/_io/bufferedio.c:558: undefined reference to `__imp__PyExc_BlockingIOError'
/cygdrive/c/Users/bcurtin/cygwin-python/release27-maint/Modules/_io/bufferedio.c:558: undefined reference to `__imp__PyExc_BlockingIOError'

My Linux compile (gcc 4.5.0) gets the same warning, but no error. Windows is totally fine with _iomodule.c:172.


This was found by Ben Walker.



[0] http://cygwin.com/ml/cygwin-announce/2010-01/msg00002.html

The _io module appears both in setup.py and Modules/Setup.dist. Is it normal?
IMO if the _io module is built-in, it should not be built as an extension module.

Should release27-maint/Modules/_io/_iomodule.c:172 be:

PyAPI_DATA(PyObject *) PyExc_BlockingIOError = (PyObject *)&_PyExc_BlockingIOError;

?

Why should it be?

patch of patch attached to issue 3871
--- ./Modules/_io/_iomodule.h.MINGW	2009-12-23 12:52:04.000000000 +0200
+++ ./Modules/_io/_iomodule.h	2009-12-14 22:01:16.000000000 +0200
@@ -72,7 +72,7 @@
     PyObject *filename; /* Not used, but part of the IOError object */
     Py_ssize_t written;
 } PyBlockingIOErrorObject;
-PyAPI_DATA(PyObject *) PyExc_BlockingIOError;
+extern PyObject* PyExc_BlockingIOError;
 
 /*
  * Offset type for positioning.

> Why should it be?

The error indicates that the definition in the .c file doesn't match the declaration in the .h file, with respect to the funky Windows-specific stuff ('dllimport') that PyAPI_DATA adds.

Roumen's patch suggests I had it backwards, and it's the .h file that should be changed.

2010/8/23 Daniel Stutzbach <report@bugs.python.org>:
>
> Daniel Stutzbach <daniel@stutzbachenterprises.com> added the comment:
>
>> Why should it be?
>
> The error indicates that the definition in the .c file doesn't match the declaration in the .h file, with respect to the funky Windows-specific stuff ('dllimport') that PyAPI_DATA adds.
>
> Roumen's patch suggests I had it backwards, and it's the .h file that should be changed.

Why would this not be required for the standard exceptions then?

I have been using the following patch to fix the issue locally for a few weeks now (in addition to something equivalent to what Brian submitted for the _curses issue). These two patches combined give me a working python 2.7 on cygwin 1.7. I originally used something identical to Roumen's patch, but later started using the patch below after reading up on __declspec. Note that line 740 is also a candidate to be changed to dllexport, but I don't have the setup to test that.

Index: Include/pyport.h
===================================================================
--- Include/pyport.h    (revision 84288)
+++ Include/pyport.h    (working copy)
@@ -739,7 +739,7 @@
 #                       if !defined(__CYGWIN__)
 #                               define PyAPI_FUNC(RTYPE) __declspec(dllimport)
RTYPE
 #                       endif /* !__CYGWIN__ */
-#                       define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE
+#                       define PyAPI_DATA(RTYPE) extern __declspec(dllexport) RTYPE
             /* module init functions outside the core must be exported */
 #                       if defined(__cplusplus)
 #                               define PyMODINIT_FUNC extern "C" __declspec(dllexport) void

Ben, import of variables cannot be changed to export as this will produce crash in application ("core dump"/"bus error" etc.) that try to use them.

> Why would this not be required for the standard exceptions then?

It looks like PyAPI_DATA can be defined differently depending on whether we're building code as a built-in or as a loadable module.  If _iomodule.c is really being built as a module, that would explain why there's a difference.  The standard exceptions are always built-in.

In Python 2.7, _io is not the default I/O system for Python, so I could understand why it might be a loadable module there.  Of course, if Amaury is right that it's being built both ways then I assume that could be the underlying problem.

Also, the definition of PyAPI_DATA has a bunch of conditions specifically for Cygwin, which (partially) explains why the behavior is different from a regular Windows build.

I am not an export on the dllimport and dllexport keywords, although I have needed to use them on occasion.  I am speculating.

This patch lets everything build ok, but a run of regrtest segfaults usually after a few tests (using -r) and there are nearly constant stack traces printed to stderr about not being able to remap the Cygwin bz2 DLL's address space.

I used extern as Roumen suggested, plus my curses hack, and added a #ifndef in Modules/main.c that was causing a problem without it.

Stage needs setting to "patch review", any volunteers to undertake a review?

PATH_MAX in duplicate with issue8548

Instead to modify BASECFLAGS user could configure with CPPFLAGS set if symbolic links are missing .
In addition 5.9 package creates links so work around is not required .

Please close as invalid.

I think this issue can probably be closed.  It refers to a very old version of Cygwin as well as old versions of Python.  I don't have any problem building the _curses or _io modules on recent versions of Cygwin (>=2.9) and with current cpython master (3.9.0a0).