MicroPython v1.13-148-ged7ddd4 ("latest" in 2022) build issues

[WebDust21]

I have been trying to get MicroPython to work as necessary for a project. RT-Thread compiles if you enable just MicroPython with no modules enabled.

But when I enable MicroPython modules from ("scons --menuconfig"), compilation fails. (I am using GCC on Ubuntu 22.04 LTS x64. All compiling tests here have been done with the "qemu-vexpress-a9" BSP.)

With "ujson" enabled, compilation fails with these errors:

CC build/packages/micropython-latest/extmod/modujson.o
packages/micropython-latest/extmod/modujson.c: In function 'mod_ujson_load':
packages/micropython-latest/extmod/modujson.c:222:32: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
                 stack_top_type = mp_obj_get_type(stack_top);
                                ^
packages/micropython-latest/extmod/modujson.c:230:28: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
             stack_top_type = mp_obj_get_type(stack_top);
                            ^
packages/micropython-latest/extmod/modujson.c:258:32: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
                 stack_top_type = mp_obj_get_type(stack_top);
                                ^

"modujson.c:222" is the following:

                stack_top_type = mp_obj_get_type(stack_top);

The problem appears to be that "mp_obj_get_type" is defined as CONST in obj.h:764, as follows:

const mp_obj_type_t *mp_obj_get_type(mp_const_obj_t o_in);

However, this is the same as the original MicroPython source. I am not sure why it is being a problem here.

to make it compile, I adjust the 3 lines in "modujson.c" (222, 230, 258) with a non-const typecast, like here:

[.....] = (mp_obj_type_t*)mp_obj_get_type(stack_top);

---

Next build problem:

CC build/packages/micropython-latest/port/modules/machine/machine_uart.o
packages/micropython-latest/port/modules/machine/machine_uart.c: In function 'machine_uart_ioctl':
packages/micropython-latest/port/modules/machine/machine_uart.c:253:12: error: return makes integer from pointer without a cast [-Werror=int-conversion]
     return NULL;
            ^~~~

The offending routine: machine_uart.c:252-254:

STATIC mp_uint_t machine_uart_ioctl(mp_obj_t obj, mp_uint_t request, uintptr_t arg, int *errcode) {
    return NULL;
}

This routine has been turned into a stub in the RT-Thread port.

• NULL is not a valid return value for "mp_uint_t".

An easy solution is to change the line to:

return -1;

---

Next build problem:

CC build/packages/micropython-latest/port/mpgetcharport.o
packages/micropython-latest/port/mpgetcharport.c: In function 'getchar_rx_ind':
packages/micropython-latest/port/mpgetcharport.c:49:17: error: implicit declaration of function 'mp_keyboard_interrupt' [-Werror=implicit-function-declaration]
                 mp_keyboard_interrupt();
                 ^~~~~~~~~~~~~~~~~~~~~

The problematic lines in "mpgetcharport.c":47-55:

        if (rt_device_read(dev, 0, &ch, 1)) {
            if (ch == mp_interrupt_char) {
                mp_keyboard_interrupt();
            } else {
                int_lvl = rt_hw_interrupt_disable();
                rt_ringbuffer_put_force(rx_fifo, &ch, 1);
                rt_hw_interrupt_enable(int_lvl);
            }

"mp_keyboard_interrupt" can be found in "/py/scheduler.c"

• if we #include "scheduler.c", compilation fails due to duplicate definitions

solution I find is to add an "extern" definition for "mp_keyboard_interrupt" at line 36 of "mpgetcharport.c":

extern void mp_keyboard_interrupt(void);

---

Next build problem:

CC build/packages/micropython-latest/py/objtype.o
packages/micropython-latest/py/objtype.c:375:25: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
     [MP_UNARY_OP_INT] = MP_QSTR___int__,
                         ^~~~~~~~~~~~~~~
packages/micropython-latest/py/objtype.c:469:32: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
     [MP_BINARY_OP_NOT_EQUAL] = MP_QSTR___ne__,
                                ^~~~~~~~~~~~~~
packages/micropython-latest/py/objtype.c:493:35: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
     [MP_BINARY_OP_MAT_MULTIPLY] = MP_QSTR___matmul__,
                                   ^~~~~~~~~~~~~~~~~~

This problem results from the QSTRdefs being generated incorrectly. Most all QSTRs in "objtype.c" must have a QDEF index less than 255. Index is basically sequential to line number in the "qstrdefs.generated.h", so if these definitions are at lines more than 255, compilation will fail.

If we search "/port/genhdr/qstrdefs.generated.h", we find:

• "MP_QSTR___int__" is at line 682
• "MP_QSTR___ne__" is at line 780
• "MP_QSTR___matmul__" is at line 776

All 3 of these entries must be moved to line numbers <255. I manually moved them to around line 150-152 in the file.

A new solution is to implement my automatic QSTR generation script, which ensures that all QSTRs needed by "objtype.c" and several other files, all have the necessary QSTRdefs index < 255.

---

Next build problem:

LINK rtthread.elf
build/packages/micropython-latest/port/modules/machine/modmachine.o: In function `machine_info':
[.........]/qemu-vexpress-a9/packages/micropython-latest/port/modules/machine/modmachine.c:69: undefined reference to `list_mem'

This one has me stumped. I cannot find "list_mem" in any source file in the entire RT-Thread folder.

Perhaps this is due to a RT-Thread configuration / invalid MicroPython setup configuration?

My solution is to comment out the call in "modmachine.c":69:

#ifdef RT_USING_MEMHEAP_AS_HEAP
        list_memheap();
#else
//        list_mem();    -> cannot find this call anywhere
#endif

---

Another compilation issue resulting from RT-Thread configuration, is the following error:

fatal error: dfs_posix.h: No such file or directory

from other RT-Thread information, I discovered that I needed to enable legacy support (RT-Thread Components -> Support Legacy Version for Compatibility). Is there any plan to fix this, so the legacy version can be completely removed?

I hope these findings can help improve RT-Thread's MicroPython success.

There are more problems I am trying to find out at the current time:

• any MicroPython callback results in RT-Thread crashing
• any access of the MicroPython "machine.Timer" results in MicroPython locking up indefinitely