On systems where configure is unable to find langinfo.h (or where nl_langinfo() is not defined), configure undefines HAVE_LANGINFO_H in pyconfig.h.  Then in pythonrun.c:get_locale_encoding() the call to nl_langinfo() is wrapped in an #ifdef, but the #else path on the ifdef does a PyErr_SetNone(PyExc_NotImplementedError) and returns NULL, which  causes initfsencoding() to fail with the message "Py_Initialize: Unable to get the locale encoding", which causes the interpreter to abort.

I'm confused because http://bugs.python.org/issue8610 (from 2010) seems to have come down on the side of deciding that nl_langinfo() failures should be treated as implicitly returning either "ASCII" or "UTF-8" (I'm not sure which).  But maybe that was for a different part of the interpreter?

In any case there are 4 choices here, all of which are preferable to what we are doing now.

1. Fail during configure.  If we can't even start the interpreter, then why waste the users time with the build?
2. Fail during compilation.  The #else path could contain #error "Python only works on systems where nl_langinfo() is correctly implemented."  Again, this would be far preferable to failing only once the user has finished the install and tries to get the interpreter prompt.
3. Implement our own python_nl_langinfo() that we fall back on when the system one doesn't exist.  (It could, for example, return "ASCII" (or "ANSI_X3.4-1968") to start with, and "UTF-8" after we see a call to setlocale(LC_CTYPE, "") or setlocale(LC_ALL, "").
4. just return the string "ASCII".

The attached patch does the last.  I'm willing to try to write the patch for choice (3) if that's what you'd prefer.  (I have an implementation that does (3) for systems that also don't have setlocale() implemented, but I don't yet know how to do it if nl_langinfo() doesn't exist but setlocale() does.)