I believe attached issue4846.diff should fix the problem, but I don't 
have access to the affected platform (Windows?), so I did not test it.

I also wonder whether it would be more appropriate to redefine PyAPI_* 
macros to declare API symbols with extern "C" when compiled under C++?  
This seems to be a better approach than cluttering all header files with 
#ifdef __cplusplus and worrying about the scope of extern "C" {} 
wrappers.

Note that I considered whether _Py_ascii_whitespace declaration should 
be done inside if !defined(HAVE_USABLE_WCHAR_T) .. directive and 
concluded that it should not.  My reasoning is as follows: _Py_ascii_whitespace must be defined unconditionally in the .c file 
because when python core is compiled, it is not known how an extension 
module would define HAVE_USABLE_WCHAR_T.  While it is not strictly 
necessary to bring _Py_ascii_whitespace definition in an extension 
module that has "USABLE_WCHAR_T", there is little to be gained from 
hiding it because it is visible to the linker.  Thus for the common uses 
there is little practical difference between the two options but 
unconditional declaration requires less code.  On the other hand in the 
context of issue4805, having unconditional declaration would allow 
removing extern "C" wrappers from unicodeobject.c without loosing C++ 
compilability of python core.