This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Buid issues on Cygwin - _curses, _curses_panel, and _io
Type: compile error Stage: resolved
Components: Build, Cross-Build Versions: Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, arifwn, benjamin.peterson, bwalker, erik.bray, jlt63, rpetrov, stutzbach, tim.golden
Priority: normal Keywords: patch

Created on 2010-08-23 21:31 by brian.curtin, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
ncurses_fix.diff brian.curtin, 2010-08-23 21:31 patch for 2.7 on cygwin
issue9665.diff brian.curtin, 2010-08-24 00:08 py3k patch
Messages (14)
msg114738 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-08-23 21:31
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.

msg114741 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2010-08-23 21:52
The _io module appears both in and Modules/Setup.dist. Is it normal?
IMO if the _io module is built-in, it should not be built as an extension module.
msg114742 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-08-23 21:58
Should release27-maint/Modules/_io/_iomodule.c:172 be:

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

msg114744 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-08-23 22:01
Why should it be?
msg114745 - (view) Author: Roumen Petrov (rpetrov) * Date: 2010-08-23 22:09
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.
msg114749 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-08-23 22:21
> 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.
msg114750 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2010-08-23 22:26
2010/8/23 Daniel Stutzbach <>:
> Daniel Stutzbach <> 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?
msg114751 - (view) Author: Ben Walker (bwalker) Date: 2010-08-23 22:36
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)
 #                       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
msg114759 - (view) Author: Roumen Petrov (rpetrov) * Date: 2010-08-23 23:44
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.
msg114760 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2010-08-23 23:58
> 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.
msg114761 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-08-24 00:08
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.
msg224252 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-29 21:10
Stage needs setting to "patch review", any volunteers to undertake a review?
msg224620 - (view) Author: Roumen Petrov (rpetrov) * Date: 2014-08-03 08:55
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.
msg345323 - (view) Author: Erik Bray (erik.bray) * (Python triager) Date: 2019-06-12 11:48
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).
Date User Action Args
2022-04-11 14:57:05adminsetgithub: 53874
2019-06-20 05:27:35methanesetstatus: open -> closed
resolution: out of date
stage: needs patch -> resolved
2019-06-12 11:48:23erik.braysetnosy: + erik.bray
messages: + msg345323
2019-04-26 20:22:57BreamoreBoysetnosy: - BreamoreBoy
2014-08-03 08:55:39rpetrovsetmessages: + msg224620
2014-07-29 21:35:57brian.curtinsetnosy: - brian.curtin
2014-07-29 21:10:00BreamoreBoysetversions: + Python 3.4, Python 3.5, - Python 3.1, Python 3.2
nosy: + BreamoreBoy, jlt63

messages: + msg224252

components: + Cross-Build, - Extension Modules, Windows
2012-05-29 06:15:49arifwnsetnosy: + arifwn
2010-09-24 14:59:51brian.curtinsetassignee: brian.curtin ->
2010-08-24 00:08:18brian.curtinsetkeywords: patch, patch
files: + issue9665.diff
messages: + msg114761
2010-08-23 23:58:11stutzbachsetkeywords: patch, patch

messages: + msg114760
2010-08-23 23:44:48rpetrovsetmessages: + msg114759
2010-08-23 22:36:34bwalkersetnosy: + bwalker
messages: + msg114751
2010-08-23 22:26:02benjamin.petersonsetmessages: + msg114750
2010-08-23 22:21:52stutzbachsetkeywords: patch, patch

messages: + msg114749
2010-08-23 22:09:46rpetrovsetnosy: + rpetrov
messages: + msg114745
2010-08-23 22:01:06benjamin.petersonsetkeywords: patch, patch
nosy: + benjamin.peterson
messages: + msg114744

2010-08-23 21:58:41stutzbachsetkeywords: patch, patch

messages: + msg114742
2010-08-23 21:52:30amaury.forgeotdarcsetkeywords: patch, patch
nosy: + amaury.forgeotdarc
messages: + msg114741

2010-08-23 21:31:58brian.curtincreate