lv_binding_micropython: Build error for STM32 port due to `free()` macro

https://github.com/littlevgl/lv_micropython

There is a build error with lv_micropython when trying to build for an STM32 port (BUILD=OLIMEX_E407).

$ make -C ports/stm32/ BOARD=OLIMEX_E407
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
GEN build-OLIMEX_E407/genhdr/qstr.i.last
../../lib/lv_bindings/lvgl/lv_misc/lv_fs.c:452:46: error: macro "free" passed 2 arguments, but takes just 1
         res = drv->free(&total_tmp, &free_tmp);
                                              ^
^Cmake: *** Deleting file `build-OLIMEX_E407/genhdr/qstr.i.last'
make: *** [build-OLIMEX_E407/genhdr/qstr.i.last] Interrupt: 2

I think the issues is due to the free() macro defined in mpcconfigport.h

$ find . -name "*.h" | xargs grep --color "define *free("
./ports/stm32/mpconfigport.h:#define free(p) m_free(p)

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 28 (15 by maintainers)

Commits related to this issue

Workaround for stray 'free' macro Related to littlevgl/lv_binding_micropython#11 'Build error for STM32 port due to 'free()' macro' — committed to amirgon/lvgl by amirgon 5 years ago

Most upvoted comments

@amirgon Let’s just add the #undef without any #ifdef wrappers.

embeddedt on Mar 2, 2019

Fixed on micropython upstream by micropython/micropython@781947a.

amirgon on Mar 26, 2019

Forgot to update git sub modules… I’ve updated them just now so lv_micropython contains this workaround.

amirgon on Mar 3, 2019

@amirgon @embeddedt

Okay, all that being said I vote for simply adding the #undef without checking the Micropython environment.

As @amirgon said:

If, for example, someone defines free from some H file unrelated to micropython, you’d get the same problem

If someone had a #define free xxx then it would already cause issues for him too (assuming USE_LV_FILESYSTEM 1) but nobody reported a similar issue so far. So I believe we won’t break existing codes.

(This fix won’t be required in v6.0 as the function has renamed)

kisvegabor on Mar 1, 2019

@amirgon I don’t expect any side effect from simply #undef free but maybe @embeddedt can tell any. I think the reason behind is to reduce the scope of the hack to minimize the probability of issue due to it. There can be other non-trivial cases which can’t be foreseen.

kisvegabor on Mar 1, 2019