classification
Title: _cursesmodule compile error in OS X 32-bit-only installer build
Type: compile error Stage: resolved
Components: Build, Macintosh Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: ned.deily Nosy List: georg.brandl, haypo, ned.deily, python-dev
Priority: release blocker Keywords:

Created on 2012-03-07 22:59 by ned.deily, last changed 2012-08-06 13:53 by ned.deily. This issue is now closed.

Messages (9)
msg155130 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-03-07 22:59
./Modules/_cursesmodule.c:279: error: syntax error before 'cchar_t'
/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c: In function 'PyCurses_ConvertToCchar_t':
./Modules/_cursesmodule.c:289: error: 'obj' undeclared (first use in this function)/Users/sysadmin/build/v3.3.0a1/Modules/_cursesmodule.c:279: error: syntax error before 'cchar_t'

Note to self, this installer build builds its own version of ncurses. It may need adjusting for 3.3.
msg163206 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-06-19 20:09
Is this issue still valid?
msg163220 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-06-19 20:45
It was still valid as of 3.3.0a4.
msg163261 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2012-06-20 07:12
And will you fix it for beta1, or do you think it can be done later?

BTW, what is the syntax error here?  I don't really see it...
msg163305 - (view) Author: Roundup Robot (python-dev) Date: 2012-06-21 06:48
New changeset 2035c5ad4239 by Ned Deily in branch 'default':
Issue #14225: Fix Unicode support for curses (#12567) on OS X:
http://hg.python.org/cpython/rev/2035c5ad4239
msg163307 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-06-21 07:06
It turns out that the Unicode support for curses did not build correctly on OS X at all.  There were two issues:

1. On OS X, unlike many systems, does not supply separate libncurses and libncursesw in /usr/lib; same for libpanel/libpanelw. So the tests in setup.py based on the presence of the "w" libs failed, thus disabling the wide-char support in the extension modules even though the OS X libs supported it.  The tests in setup.py are now fixed to handle building on OS X with either the system libs or locally-supplied copies.

2. The 32-bit-only installer has historically built and supplied its own copy of libncursesw so that installer build did find a wide lib.  However, the wide code support within ncurses is conditional depending on _XOPEN_SOURCE_EXTENDED which is specifically not defined for OS X  (platform=='darwin') builds.  That caused the compile errors (things like cchar_t from the ncurses include files were not getting defined).  The solution for that is to supply _XOPEN_SOURCE_EXTENDED locally to the _curses* extension module builds.
msg163313 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2012-06-21 08:47
Cool, thanks for the fix!
msg163323 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-06-21 10:52
P.S. All is not perfect.  I initially missed re-running test_curses with the system ncurses library on OS X where ncurses is at 5.4 or with the 32-bit-installer which builds ncurses 5.5.  When I did, test_curses failed as described in Issue15037.  test_curses passes when Python is built with a MacPorts ncurses 5.9.  The best solution would be to update the installer builds to build and use the latest ncurses 5.9.  That may have to wait until after 3.3.0b1.
msg167565 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-08-06 13:53
P.P.S. I've updated the OS X installers as of 3.3.0b2 to build and link with a local copy of ncurses 5.9 rather than older Apple-supplied ones.  test_curses now passes.
History
Date User Action Args
2012-08-06 13:53:18ned.deilysetmessages: + msg167565
2012-06-21 10:52:13ned.deilysetmessages: + msg163323
2012-06-21 08:47:14hayposetnosy: + haypo
messages: + msg163313
2012-06-21 07:06:31ned.deilysetstatus: open -> closed
resolution: fixed
messages: + msg163307

stage: resolved
2012-06-21 06:48:40python-devsetnosy: + python-dev
messages: + msg163305
2012-06-20 07:12:23georg.brandlsetmessages: + msg163261
2012-06-19 20:45:40ned.deilysetmessages: + msg163220
2012-06-19 20:09:51georg.brandlsetnosy: + georg.brandl
messages: + msg163206
2012-03-07 22:59:45ned.deilycreate