[issue42358] Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian value on nigendan system
Dennis Clarke
report at bugs.python.org
Sat Nov 14 15:01:41 EST 2020
New submission from Dennis Clarke <dclarke at 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 <report at bugs.python.org>
<https://bugs.python.org/issue42358>
_______________________________________
More information about the Python-bugs-list
mailing list