Seems related to issue42173 where the idea on the table was, simply to
drop Solaris support and to quote Mr Stinner to "let the code slowly
die".  Regardless of this sort of neglect there are people who do try
to use Python on big endian risc systems such as Solaris or Debian Linux
in fact. Wherein a trivial configure reveals : 

alpha$ ../Python-3.9.0/configure --prefix=/opt/bw \
> --enable-shared --disable-optimizations \
> --enable-loadable-sqlite-extensions \
> --enable-ipv6 --with-pydebug --without-dtrace \
> --with-openssl=/opt/bw --with-ssl-default-suites=openssl \
> --without-gcc
configure: WARNING: unrecognized options: --without-gcc
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking for python3.9... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "sunos5"
checking for gcc... /opt/developerstudio12.6/bin/cc -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib
checking whether the C compiler works... yes
.
.
.
checking for __fpu_control... no
checking for __fpu_control in -lieee... no
checking for --with-libm=STRING... default LIBM="-lm"
checking for --with-libc=STRING... default LIBC=""
checking for x64 gcc inline assembler... no
checking whether float word ordering is bigendian... unknown
configure: error: 

Unknown float word ordering. You need to manually preset
ax_cv_c_float_words_bigendian=no (or yes) according to your system.

So it seems that the m4/ax_c_float_words_bigendian.m4 needs to be
manually hacked or the configure script itself is at fault. 

I will give this a try on big endian IBM Power and also IBM Power9
ppc64le as well as FreeBSD running in RISC-V rv64imafdc little endian
and see what happens. I suspect that the little endian systems will
be no great concern as the bulk of Python devs seem to have never
seen anything else other than little endian systems running Red Hat.

To hack around this floating point endian test with blunt force :

alpha$ 
alpha$ diff -u configure.orig configure
--- configure.orig      Mon Oct  5 15:07:58 2020
+++ configure   Sat Nov 14 19:37:13 2020
@@ -14425,7 +14425,7 @@
 else
 
 
-ax_cv_c_float_words_bigendian=unknown
+ax_cv_c_float_words_bigendian=yes
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -14442,9 +14442,9 @@
 fi
 if $GREP seesnoon conftest.$ac_objext >/dev/null ; then
   if test "$ax_cv_c_float_words_bigendian" = unknown; then
-    ax_cv_c_float_words_bigendian=no
+    ax_cv_c_float_words_bigendian=yes
   else
-    ax_cv_c_float_words_bigendian=unknown
+    ax_cv_c_float_words_bigendian=yes
   fi
 fi
 
alpha$ 
alpha$ diff -u m4/ax_c_float_words_bigendian.m4.orig m4/ax_c_float_words_bigendian.m4
--- m4/ax_c_float_words_bigendian.m4.orig       Mon Oct  5 15:07:58 2020
+++ m4/ax_c_float_words_bigendian.m4    Sat Nov 14 19:35:44 2020
@@ -42,7 +42,7 @@
   [AC_CACHE_CHECK(whether float word ordering is bigendian,
                   ax_cv_c_float_words_bigendian, [
 
-ax_cv_c_float_words_bigendian=unknown
+ax_cv_c_float_words_bigendian=yes
 AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
 
 double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
@@ -54,9 +54,9 @@
 fi
 if $GREP seesnoon conftest.$ac_objext >/dev/null ; then
   if test "$ax_cv_c_float_words_bigendian" = unknown; then
-    ax_cv_c_float_words_bigendian=no
+    ax_cv_c_float_words_bigendian=yes
   else
-    ax_cv_c_float_words_bigendian=unknown
+    ax_cv_c_float_words_bigendian=yes
   fi
 fi
 
alpha$ 

This is a hack of course and it gets past the endian test sickness. 

Shortly thereafter the compile fails due to a trivial C99 code 
problem : 

/opt/developerstudio12.6/bin/cc -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -c  -O -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib -D_REENTRANT -std=iso9899:2011 -m64 -xarch=sparc -g -errfmt=error -errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xs -xdebugformat=dwarf -errtags=yes -errwarn=%none -erroff=%none -L/opt/bw/lib -R/opt/bw/lib    -I../Python-3.9.0/Include/internal -IObjects -IInclude -IPython -I. -I../Python-3.9.0/Include -I/opt/bw/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -I/opt/bw/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -xcode=pic32 -DPy_BUILD_CORE -o Objects/exceptions.o ../Python-3.9.0/Objects/exceptions.c
"../Python-3.9.0/Objects/exceptions.c", line 2313: error: void function cannot return value
cc: acomp failed for ../Python-3.9.0/Objects/exceptions.c
gmake: *** [Makefile:1781: Objects/exceptions.o] Error 2

However that is a separate issue that has been around for at least a year or so.

  2313    return Py_TYPE(self)->tp_free((PyObject *)self);  ???

Why try to return anything here ? 

Why can we not do the same as line 2319 ? 

  2306  
  2307  static void
  2308  MemoryError_dealloc(PyBaseExceptionObject *self)
  2309  {
  2310      BaseException_clear(self);
  2311  
  2312      if (!Py_IS_TYPE(self, (PyTypeObject *) PyExc_MemoryError)) {
  2313          Py_TYPE(self)->tp_free((PyObject *)self);
  2314      }
  2315  
  2316      _PyObject_GC_UNTRACK(self);
  2317  
  2318      if (memerrors_numfree >= MEMERRORS_SAVE)
  2319          Py_TYPE(self)->tp_free((PyObject *)self);
  2320      else {
  2321          self->dict = (PyObject *) memerrors_freelist;
  2322          memerrors_freelist = self;
  2323          memerrors_numfree++;
  2324      }
  2325  }
  2326  

The compile may then continue but eventually a bucket of tests fail.

Perhaps an Oracle/Fujitsu SPARC based built bot or site would help here?

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

I gave up on trying to compile this code with C99. Trying C11 and 
hope that blows up in different places.

> I suspect that the little endian systems will
> be no great concern as the bulk of Python devs seem to have never
> seen anything else other than little endian systems running Red Hat.

We don't fancy this kind of passive-aggressive and accusatory communication style. Instead we prefer constructive collaboration without personal attacks.

For your information our buildbot infrastructure perform regular testing on a lot of hardware platforms, distributions, and compilers including PPC64 and s390x big endian machines.

Please attach your config.log and provide more information about your platform, compiler, and hardware.

I see :

https://github.com/python/cpython/blob/master/Objects/exceptions.c#L2316 

the void return has been fixed and really I should not be
looked anywhere else other than the master sources on some
oddball platform.  I will start over.