Trent Nelson added the comment: 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. ---------- nosy: +trent resolution: -> fixed status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13843> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
