New submission from Dennis Clarke <dcla...@blastwave.org>:
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 ---------- components: Installation messages: 380987 nosy: blastwave priority: normal severity: normal status: open title: Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system versions: Python 3.9 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42358> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com