homepage

Seems unicode_empty is still NULL at this point.
A gdb backtrace from an x86_64 build. Reproduced on i686 and mips build as well.
Program received signal SIGSEGV, Segmentation fault.
0x000000000044f61e in PyUnicode_DecodeUTF8Stateful (s=0x59a767 "", size=0, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:4726
4726	 Py_INCREF(unicode_empty);
(gdb) bt
#0 0x000000000044f61e in PyUnicode_DecodeUTF8Stateful (s=0x59a767 "", size=0, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:4726
#1 0x0000000000433087 in PyType_Ready (type=0x7d5340) at Objects/typeobject.c:4235
#2 0x00000000004332ae in PyType_Ready (type=<optimized out>) at Objects/typeobject.c:4116
#3 PyType_Ready (type=0x7d54e0) at Objects/typeobject.c:4146
#4 0x000000000041bbfe in _Py_ReadyTypes () at Objects/object.c:1576
#5 0x00000000004a6eb0 in _Py_InitializeEx_Private (install_sigs=<optimized out>, install_importlib=<optimized out>) at Python/pythonrun.c:301
#6 Py_InitializeEx (install_sigs=<optimized out>) at Python/pythonrun.c:401
#7 Py_Initialize () at Python/pythonrun.c:407
#8 0x00000000004bb9fc in Py_Main (argc=1, argv=0x82f010) at Modules/main.c:646
#9 0x000000000041949e in main (argc=1, argv=0x7fffffffe658) at ./Modules/python.c:66

This seems related to #9242: _Py_InitializeEx_Private() calls _Py_ReadyTypes(),
which uses the Unicode API, well before actually calling _PyUnicode_Init().

Sorry, wrong issue number: Related to #10156.

Does this need to be a release blocker? I don't know what the concrete point of --without-doc-strings is.

The deeper issue is that globals in unicodeobject.c are used before
they are initialized. So I thought that should be cleared up before
the next release.
Basically, strings are used as keys during type initializations
*before* _PyUnicode_Init() is called.

Closing as a duplicate of #10156, which has several patches.