The code generated by version 0.24.0 has strange compilation errors

[TangHangWei]

I used arm-none-eabi-gcc to compile eez-studio 0.24.0 to generate the code for the LVGL-flow (9.1.0) project. After using the ui_tick() function in the overall project code, a compilation error occurred:

Template_Project/applications/LVGL/eez_studio/ui/eez-flow.h: In function 'lvgl_thread_entry':
Template_Project/applications/LVGL/eez_studio/ui/eez-flow.h:3410:6: error: static declaration of 'utf8casecmp' follows non-static declaration
3410 | int utf8casecmp(const utf8_int8_t *src1,
| ^~~~~~~~~~~
Template_Project/applications/LVGL/eez_studio/ui/eez-flow.h:3224:5: note: previous declaration of 'utf8casecmp' was here
3224 | int utf8casecmp(const utf8_int8_t *src1, const utf8_int8_t *src2);
| ^~~~~~~~~~~

There is more than one function, but the same error occurs.

[TangHangWei]

Here is the solution for GPT：
One-line root cause:
This header embeds the full implementation of sheredom/utf8.h. Every translation unit that includes it emits the same symbol definitions, and your toolchain/linker can’t reliably coalesce them, causing multiple-definition / ODR violations.

Details (4 points):

Amalgamated header with implementation
The end of eez-flow.h inlines the entire sheredom/utf8.h. Any .c/.cpp that #includes it produces non-internal-linkage definitions of all utf8* functions.

Relies on weak/inline coalescing
That library marks functions with attribute((weak)) (GCC/Clang) or __inline (MSVC), assuming duplicates across objects will be merged or inlined away. On some setups (e.g., certain ArmClang/AC6 versions, with LTO, or with particular link scripts), multiple weak definitions are not reliably coalesced, leading to “multiple definition” / ODR errors.

“Make it static” isn’t consistent
Only parts of the implementation are guarded by macros (e.g., utf8_constexpr14_impl may be empty), so you can end up with mismatches—e.g., a declaration changed to static while the definition still has external linkage, or both inline and non-inline variants of the same function. The conflict persists.

What Solution A does
Using -DSHEREDOM_UTF8_H_INCLUDED=1 skips the embedded sheredom implementation entirely, and -DUTF8_SUPPORT=0 enables the lightweight substitutes provided earlier in core/utf8.h (wrappers like strlen/strcmp, etc.). Then, no matter how many files include eez-flow.h, no conflicting UTF-8 symbols are emitted and the linker errors disappear.

Summary:
The header ships an external library implementation that gets compiled into every including TU; in this build/link environment, duplicate external definitions aren’t handled consistently. Solution A removes that embedded implementation via preprocessor defines and switches to a conflict-free minimal version, which is why it works immediately.

[TangHangWei]

Adding compiler options -DUTF8_SUPPORT=0 -DSHEREDOM_UTF8_H_INCLUDED=1 works