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.

Author ned.deily
Recipients georg.brandl, ned.deily, python-dev
Date 2012-06-21.07:06:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340262392.86.0.272514942556.issue14225@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-06-21 07:06:33ned.deilysetrecipients: + ned.deily, georg.brandl, python-dev
2012-06-21 07:06:32ned.deilysetmessageid: <1340262392.86.0.272514942556.issue14225@psf.upfronthosting.co.za>
2012-06-21 07:06:31ned.deilylinkissue14225 messages
2012-06-21 07:06:30ned.deilycreate