I don't know since when, because koschei does not build 32 bit, but micropython fails to build on i686 and armv7hl with: gcc -I../../lib/berkeley-db-1.xx/PORT/include -I. -I../.. -Ibuild-standard -I../../lib/mp-readline -Wall -Werror -Wpointer-arith -Wuninitialized -Wdouble-promotion -Wsign-compare -Wfloat-conversion -std=gnu99 -DUNIX -DFFCONF_H=\"lib/oofatfs/ffconf.h\" -DMICROPY_PY_USSL=1 -DMICROPY_SSL_AXTLS=1 -I../../lib/axtls/ssl -I../../lib/axtls/crypto -I../../extmod/axtls-include -DMICROPY_PY_BTREE=1 -DMICROPY_USE_READLINE=1 -DMICROPY_PY_TERMIOS=1 -DMICROPY_PY_SOCKET=1 -DMICROPY_PY_THREAD=1 -DMICROPY_PY_THREAD_GIL=0 -DMICROPY_PY_FFI=1 -Os -fdata-sections -ffunction-sections -DNDEBUG -Ivariants/standard -g -U _FORTIFY_SOURCE -DMICROPY_QSTR_EXTRA_POOL=mp_qstr_frozen_const_pool -DMICROPY_MODULE_FROZEN_MPY -DMPZ_DIG_SIZE=16 -DMICROPY_MODULE_FROZEN_STR -c -MD -o build-standard/modffi.o modffi.c make: Leaving directory '/builddir/build/BUILD/micropython-1.13/ports/unix' modffi.c: In function 'ffifunc_call': modffi.c:174:20: error: array subscript 'double[0]' is partly outside array bounds of 'ffi_arg[1]' {aka 'long unsigned int[1]'} [-Werror=array-bounds] 174 | return mp_obj_new_float_from_d(*p); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ modffi.c:365:17: note: while referencing 'val' 365 | STATIC mp_obj_t ffifunc_call(mp_obj_t self_in, size_t n_args, size_t n_kw, const mp_obj_t *args) { | ^~~~~~~~~~~~ cc1: all warnings being treated as errors This is micropython-1.13-2.fc34 and gcc-11.0.0-0.17.fc34. Maybe we should not treat all warning as error, or maybe we should filter out this particular warning. But I have not tried to figure out yet if the warning makes sense or if this is a gcc bug. In case it is legit, we might want to inform upstream. Note that we can easily exclude i686 as this is not multilib, but I'd like to keep building for armv7hl if possible.
The code the warning points to (copied below) casts ffi_arg* to double*. Browsing the sources suggests ffi_arg should be a typedef for a 64-bit integer type but if it's smaller that would explain the warning. Either way, accessing object of one type using a pointer to an incompatible type is undefined, regardless of whether they have the same size, so the code on like 174 is likely invalid. The text of the warning isn't quite clear about this and a patch I submitted upstream just last week, besides changing this instance from -Warray-bounds to -Wstrict-aliasing, adjusts its text to make the problem clearer (https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html). $ cat -n micropython-1.13/ports/unix/modffi.c | head -n180 | tail -n16 165 #if MICROPY_PY_BUILTINS_FLOAT 166 case 'f': { 167 union { ffi_arg ffi; 168 float flt; 169 } val_union = { .ffi = val }; 170 return mp_obj_new_float_from_f(val_union.flt); 171 } 172 case 'd': { 173 double *p = (double *)&val; 174 return mp_obj_new_float_from_d(*p); 175 } 176 #endif 177 case 'O': 178 return (mp_obj_t)(intptr_t)val; 179 default: 180 return mp_obj_new_int(val);
A bit more testing suggests the problem might be due to armv7hl-eabi defining ffi_arg to unsigned long: $ grep "typedef.*ffi_arg" micropython-1.13/lib/libffi/src/arm/* micropython-1.13/lib/libffi/src/arm/ffitarget.h:typedef unsigned long ffi_arg; ...which in the GCC cross for the target is a 32-bit type: $ /build/armv7hl-eabi/gcc-master/gcc/xgcc -B /build/armv7hl-eabi/gcc-master/gcc -dM -E -xc - < /dev/null | grep -e SIZEOF_LONG -e SIZEOF_DOUBLE #define __SIZEOF_LONG__ 4 #define __SIZEOF_LONG_DOUBLE__ 8 #define __SIZEOF_DOUBLE__ 8 #define __SIZEOF_LONG_LONG__ 8
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Dear Maintainer, your package has an open Fails To Build From Source bug for Fedora 34. Action is required from you. If you can fix your package to build, perform a build in koji, and either create an update in bodhi, or close this bug without creating an update, if updating is not appropriate [1]. If you are working on a fix, set the status to ASSIGNED to acknowledge this. If you have already fixed this issue, please close this Bugzilla report. Following the policy for such packages [2], your package will be orphaned if this bug remains in NEW state more than 8 weeks (not sooner than 2021-03-26). A week before the mass branching of Fedora 35 according to the schedule [3], any packages not successfully rebuilt at least on Fedora 33 will be retired regardless of the status of this bug. [1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ [2] https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ [3] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html
I finally reported this to upstream: https://github.com/micropython/micropython/issues/7064 Sorry for the long delay.
https://src.fedoraproject.org/rpms/micropython/pull-request/7
FEDORA-2021-947802b97e has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.