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 trent
Recipients amaury.forgeotdarc, jcea, loewis, pitrou, skrah, thoratsandip, trent, vstinner
Date 2012-10-18.08:15:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1350548127.18.0.0037600447065.issue13843@psf.upfronthosting.co.za>
In-reply-to
Content
I ran into this yesterday on my Solaris 10 box (nitrogen/s10), seemingly out of nowhere.

The problem is caused when a GNU libintl.h gets picked up via `#include <libintl.h>` instead of the system one in /usr/include.

In my case, this was happening because I had set CPPFLAGS to "-I/opt/csw/include -I/opt/csw/include/ncurses -I/usr/include".

The fix is to order the includes as follows: "-I/opt/csw/include/ncurses -I/usr/include -I/opt/csw/include".

The order is important: you want the /opt/csw/include/ncurses to come first, otherwise _curses won't build from the curses.h in /usr/include.  However, for libintl.h, you want the /usr/include version, not the /opt/csw/include version.

(Side note: I briefly looked at the GNU libintl.h in /opt/csw/include.  The `libintl_` function prefix is driven by some #ifdef logic, so, presumably, if you really wanted to build with the GNU libintl, you could do some #define tweaking to disable the `libintl_` prefix.  The libintl shipped with Solaris 10 seems to work fine, so I didn't bother with this.)

Closing as fixed.
History
Date User Action Args
2012-10-18 08:15:27trentsetrecipients: + trent, loewis, jcea, amaury.forgeotdarc, pitrou, vstinner, thoratsandip, skrah
2012-10-18 08:15:27trentsetmessageid: <1350548127.18.0.0037600447065.issue13843@psf.upfronthosting.co.za>
2012-10-18 08:15:27trentlinkissue13843 messages
2012-10-18 08:15:26trentcreate