I believe there is a configuration issue (flags etc.) if LTO is not working. Static libs are basically combined object files and the linker should be able apply optimization just like separately compiled object files. I’m not 100% sure though so some investigation is needed here.
@MultipleMonomials could you shine in here? 
My understanding is that INTERFACE is for a very specific use case (header-only libraries mostly) and should not be used lightly.
Mbed made the choice of INTERFACE against good practices and against the recommandation of @MultipleMonomials and their experience with USCRPL/mbed-cmake.
I’ve tried it, it works perfectly and the PR has been merged to master, so it’s ready to use.
I strongly disagree The INTERFACE is the problem to everything we have here and it’s spreading badly. Needing to change all your libs to INTERFACE as well just doesn’t make any sense.
Pushing bad practice to fix something rotten in the core project it not a good thing. It might a short term work around but it’s not the way cmake is supposed to work. The problem has been known since the beginning and the choice of INTERFACE was made to simplify and speed up the move to cmake. And once again, it was known that the choice would be causing issues later on.
I really recommend reading the following references:
- An Introduction to Modern CMake · Modern CMake
- Effective Modern CMake · GitHub
- CMake: Public VS Private VS Interface - Lei Mao's Log Book
- Modern CMake is like inheritance - Kuba Sejdak
I agree with that 
@JojoS can you share (again if I already asked) an example project to test? The memap output could also be very useful to understand where the difference is coming from.
Yeah, INTERFACE libraries are mainly used in CMake for header only libraries and other miscellaneous things (e.g. libraries that are linked via compiler flag, such as OpenMP). They are specifically meant for cases where a library doesn’t have source files. However, Mbed OS has (ab)used the “INTERFACE_SOURCES” property, which allows interface libraries to attach sources to things that link to them. It’s not a great way to do it, and I believe they only did it as a way to allow the multiple constituent libraries of Mbed OS to “share” compile definitions with each other, instead of being compiled in their own environment.
They way they did it causes a number of issues, chiefly that any non-interface library that links to the Mbed OS interface library compiles a full copy of the Mbed sources. This makes it unfeasible to have multiple executables in a project. It also means that you can’t make non-INTERFACE libraries, as these libraries would also cause a full mbed copy to be compiled. So, the way @boraozgen did it, though ugly, is required to avoid spurious compiles on the current mbed release version.
The proper solution, which is now merged to Mbed OS master branch, is mbed_create_distro(), which creates a non-INTERFACE target that builds all the mbed OS features you need once (and I had to implement BFS in CMake to do it!). This can then be linked to in executables, and you can also link your OBJECT and STATIC libraries to it, avoiding any need for janky interface libraries.
1 Like
yes, I will update my example. Currently, I have still deep nested directorys that lead to too long filenames.
this is the build with lvgl as interface lib:
-- built: D:/Projects/Sn/LocalGit/Mbed6/apps/lvgl8-ST7735/cmake_build/STM32F407VE_BLACK/release/GCC_ARM/lvgl8-ST7735.hex
| Module | .text | .data | .bss |
|---------------------------------------------|-----------------|-------------|---------------|
| 7c541cdc7fc1fe85edc532bea9a4515d\TARGET_STM | 638(+638) | 0(+0) | 0(+0) |
| D_\Projects | 125668(+125668) | 499(+499) | 43338(+43338) |
| [fill] | 248(+248) | 5(+5) | 68(+68) |
| [lib]\c.a | 8464(+8464) | 2108(+2108) | 58(+58) |
| [lib]\gcc.a | 772(+772) | 0(+0) | 0(+0) |
| [lib]\misc | 188(+188) | 4(+4) | 28(+28) |
| b5b41367bfe894d6b4193ae4cb855ac9\targets | 7530(+7530) | 0(+0) | 0(+0) |
| main.cpp.obj | 988(+988) | 0(+0) | 180(+180) |
| Subtotals | 144496(+144496) | 2616(+2616) | 43672(+43672) |
Total Static RAM memory (data + bss): 46288(+46288) bytes
Total Flash memory (text + data): 147112(+147112) bytes
and this with lvgl static build:
-- built: D:/Projects/Sn/LocalGit/Mbed6/apps/lvgl8-ST7735/cmake_build/STM32F407VE_BLACK/release/GCC_ARM/lvgl8-ST7735.hex
| Module | .text | .data | .bss |
|---------------------------------------------|-----------------|-------------|---------------|
| 7c541cdc7fc1fe85edc532bea9a4515d\TARGET_STM | 638(+638) | 0(+0) | 0(+0) |
| D_\Projects | 22466(+22466) | 440(+440) | 9545(+9545) |
| [fill] | 240(+240) | 5(+5) | 59(+59) |
| [lib]\c.a | 8464(+8464) | 2108(+2108) | 58(+58) |
| [lib]\gcc.a | 772(+772) | 0(+0) | 0(+0) |
| [lib]\lvgl.a | 210602(+210602) | 59(+59) | 33794(+33794) |
| [lib]\misc | 188(+188) | 4(+4) | 28(+28) |
| b5b41367bfe894d6b4193ae4cb855ac9\targets | 7530(+7530) | 0(+0) | 0(+0) |
| main.cpp.obj | 988(+988) | 0(+0) | 180(+180) |
| Subtotals | 251888(+251888) | 2616(+2616) | 43664(+43664) |
Total Static RAM memory (data + bss): 46280(+46280) bytes
Total Flash memory (text + data): 254504(+254504) bytes
The sources are still here:
The CMakeLists.txt is for the test of my new project structure. It could be changed to the standard Mbed build scheme by modifying the add_subdirectory() calls. The .lib files are present for the mbed-tools deploy command, but I haven’t tested it yet.
About LTO: this is a very long on-off story in Mbed, the lto support from gcc was not good in older versions. Now it looks ok, but obviously it is an difference with static libs. I have shortly googled for this, some extra steps are neccessary. Maybe its easier with cmake?
I’m not against static libs, but code size should be the same. I still see no big difference in single object files vs. packed object files, but I will follow the more experienced users. Its only important to have the sources, so that the lib can be rebuild when something in the header changes. With mbed2 and the precompiled libs, it was not possible. There I used also the -dev package that included the source files. But mbed2 compiled in seconds…
Yes, no difference. The static contains a lot of functions that are never called. The map file is long and hard to compare.
Memap.py has more depth levels for more details, I guess that can be easily passed to the memap.py via cmake. But tomorrow, yesterday was late with damned windows path length problem.
I have updated my repo and the the project structure can be switched via settings in cmake config.
I have also created a mbed-os branch for setting the memap depth. It maybe better to use options rather than variables, but I have not used these options for now.
This is again the output from memap, but with more detailed depth. You see that all modules are pulled in when a static lib is used.
I have deleted some lines, message got to long.
Memap output
-- built: /home/jojo/projects/Mbed6-Projects/apps/lvgl8-ST7735/cmake_build/STM32F407VE_BLACK/release/GCC_ARM/lvgl8-ST7735.hex
| Module | .text | .data | .bss |
|-------------------------------------------------------------------------------|-----------------|-------------|---------------|
| [fill] | 250(+250) | 5(+5) | 58(+58) |
| [lib]/lvgl.a/lv_anim.c.obj | 1560(+1560) | 0(+0) | 10(+10) |
| [lib]/lvgl.a/lv_arc.c.obj | 5402(+5402) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_area.c.obj | 2284(+2284) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_bar.c.obj | 3984(+3984) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_btn.c.obj | 70(+70) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_btnmatrix.c.obj | 8366(+8366) | 28(+28) | 0(+0) |
| [lib]/lvgl.a/lv_checkbox.c.obj | 1902(+1902) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_color.c.obj | 746(+746) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_disp.c.obj | 388(+388) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_draw_arc.c.obj | 8208(+8208) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_draw_blend.c.obj | 6292(+6292) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_draw_img.c.obj | 4048(+4048) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_draw_label.c.obj | 3970(+3970) | 0(+0) | 261(+261) |
| [lib]/lvgl.a/lv_draw_line.c.obj | 4456(+4456) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_draw_mask.c.obj | 10252(+10252) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_draw_rect.c.obj | 13304(+13304) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_dropdown.c.obj | 5630(+5630) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_event.c.obj | 1272(+1272) | 0(+0) | 4(+4) |
| [lib]/lvgl.a/lv_extra.c.obj | 14(+14) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_flex.c.obj | 5962(+5962) | 0(+0) | 14(+14) |
| [lib]/lvgl.a/lv_font.c.obj | 138(+138) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_font_fmt_txt.c.obj | 1550(+1550) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_font_montserrat_10.c.obj | 0(+0) | 0(+0) | 8(+8) |
| [lib]/lvgl.a/lv_font_montserrat_14.c.obj | 0(+0) | 0(+0) | 8(+8) |
| [lib]/lvgl.a/lv_font_montserrat_18.c.obj | 0(+0) | 0(+0) | 8(+8) |
| [lib]/lvgl.a/lv_fs.c.obj | 642(+642) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_gc.c.obj | 0(+0) | 0(+0) | 520(+520) |
| [lib]/lvgl.a/lv_grid.c.obj | 5632(+5632) | 0(+0) | 26(+26) |
| [lib]/lvgl.a/lv_group.c.obj | 1758(+1758) | 0(+0) | 4(+4) |
| [lib]/lvgl.a/lv_hal_disp.c.obj | 1036(+1036) | 0(+0) | 4(+4) |
| [lib]/lvgl.a/lv_hal_indev.c.obj | 348(+348) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_hal_tick.c.obj | 130(+130) | 0(+0) | 5(+5) |
| [lib]/lvgl.a/lv_img_buf.c.obj | 5318(+5318) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_img_cache.c.obj | 128(+128) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_img_decoder.c.obj | 4186(+4186) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_indev.c.obj | 6600(+6600) | 0(+0) | 9(+9) |
| [lib]/lvgl.a/lv_indev_scroll.c.obj | 5158(+5158) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_label.c.obj | 5970(+5970) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_led.c.obj | 1024(+1024) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_line.c.obj | 834(+834) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_ll.c.obj | 802(+802) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_math.c.obj | 868(+868) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_mem.c.obj | 2916(+2916) | 4(+4) | 32772(+32772) |
| [lib]/lvgl.a/lv_meter.c.obj | 5968(+5968) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_obj.c.obj | 6188(+6188) | 0(+0) | 5(+5) |
| [lib]/lvgl.a/lv_obj_class.c.obj | 844(+844) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_obj_draw.c.obj | 4234(+4234) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_obj_pos.c.obj | 9944(+9944) | 0(+0) | 5(+5) |
| [lib]/lvgl.a/lv_obj_scroll.c.obj | 8202(+8202) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_obj_style.c.obj | 7164(+7164) | 1(+1) | 0(+0) |
| [lib]/lvgl.a/lv_obj_style_gen.c.obj | 252(+252) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_obj_tree.c.obj | 988(+988) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_printf.c.obj | 3496(+3496) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_refr.c.obj | 5520(+5520) | 0(+0) | 8(+8) |
| [lib]/lvgl.a/lv_slider.c.obj | 3962(+3962) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_style.c.obj | 2112(+2112) | 2(+2) | 0(+0) |
| [lib]/lvgl.a/lv_style_gen.c.obj | 1490(+1490) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_switch.c.obj | 1766(+1766) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_theme.c.obj | 214(+214) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_theme_default.c.obj | 7630(+7630) | 0(+0) | 106(+106) |
| [lib]/lvgl.a/lv_timer.c.obj | 896(+896) | 0(+0) | 17(+17) |
| [lib]/lvgl.a/lv_tlsf.c.obj | 3068(+3068) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_txt.c.obj | 2758(+2758) | 24(+24) | 0(+0) |
| [lib]/lvgl.a/lv_utils.c.obj | 126(+126) | 0(+0) | 0(+0) |
| [lib]/lvgl.a/lv_win.c.obj | 136(+136) | 0(+0) | 2(+2) |
| [lib]/misc/crt0.o | 124(+124) | 0(+0) | 0(+0) |
| [lib]/misc/crtbegin.o | 64(+64) | 4(+4) | 28(+28) |
| [lib]/misc/crtend.o | 0(+0) | 0(+0) | 0(+0) |
| [lib]/misc/crti.o | 0(+0) | 0(+0) | 0(+0) |
| [lib]/misc/crtn.o | 0(+0) | 0(+0) | 0(+0) |
| custom_targets/TARGET_STM32F4/TARGET_STM32F407VE_BLACK/PeripheralPins.c.obj | 0(+0) | 0(+0) | 0(+0) |
| lvglDriver/LVGLDispDriverBase.cpp.obj | 46(+46) | 0(+0) | 0(+0) |
| lvglDriver/LVGLDispDriver_GC9A01.cpp.obj | 758(+758) | 0(+0) | 0(+0) |
| lvglDriver/LVGLInputDriverBase.cpp.obj | 30(+30) | 0(+0) | 0(+0) |
| lvglDriver/LVGLTouchDriverXPT2046.cpp.obj | 642(+642) | 0(+0) | 4(+4) |
| lvglDriver/TARGET_STM32F407VE_BLACK/LVGLDispDriverSTM32F407VE_BLACK.cpp.obj | 680(+680) | 0(+0) | 236(+236) |
| lvglDriver/TARGET_STM32F407VE_BLACK/LVGLTouchDriver_STM32F407VE_BLACK.cpp.obj | 120(+120) | 0(+0) | 240(+240) |
| lvglDriver/TARGET_STM32F407VE_BLACK/ili9341_fsmc.cpp.obj | 238(+238) | 0(+0) | 0(+0) |
| main.cpp.obj | 988(+988) | 0(+0) | 180(+180) |
| Subtotals | 251296(+251296) | 2616(+2616) | 43696(+43696) |
Total Static RAM memory (data + bss): 46312(+46312) bytes
Total Flash memory (text + data): 253912(+253912) bytes
-- built: /home/jojo/projects/Mbed6-Projects/apps/lvgl8-ST7735/cmake_build/STM32F407VE_BLACK/release/GCC_ARM/lvgl8-ST7735.hex
| Module | .text | .data | .bss |
|-------------------------------------------------------------------------------|-----------------|-------------|---------------|
| [fill] | 264(+264) | 5(+5) | 67(+67) |
0(+0) | 0(+0) |
| lvgl/src/core/lv_disp.c.obj | 184(+184) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_event.c.obj | 530(+530) | 0(+0) | 4(+4) |
| lvgl/src/core/lv_group.c.obj | 914(+914) | 0(+0) | 4(+4) |
| lvgl/src/core/lv_indev.c.obj | 3214(+3214) | 0(+0) | 8(+8) |
| lvgl/src/core/lv_indev_scroll.c.obj | 2594(+2594) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_obj.c.obj | 3122(+3122) | 0(+0) | 5(+5) |
| lvgl/src/core/lv_obj_class.c.obj | 432(+432) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_obj_draw.c.obj | 1616(+1616) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_obj_pos.c.obj | 4836(+4836) | 0(+0) | 5(+5) |
| lvgl/src/core/lv_obj_scroll.c.obj | 4132(+4132) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_obj_style.c.obj | 3316(+3316) | 1(+1) | 0(+0) |
| lvgl/src/core/lv_obj_style_gen.c.obj | 72(+72) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_obj_tree.c.obj | 512(+512) | 0(+0) | 0(+0) |
| lvgl/src/core/lv_refr.c.obj | 3022(+3022) | 0(+0) | 8(+8) |
| lvgl/src/core/lv_theme.c.obj | 114(+114) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_draw_arc.c.obj | 3522(+3522) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_draw_blend.c.obj | 3018(+3018) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_draw_img.c.obj | 2136(+2136) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_draw_label.c.obj | 2344(+2344) | 0(+0) | 261(+261) |
| lvgl/src/draw/lv_draw_line.c.obj | 2080(+2080) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_draw_mask.c.obj | 3978(+3978) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_draw_rect.c.obj | 7522(+7522) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_img_buf.c.obj | 2246(+2246) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_img_cache.c.obj | 88(+88) | 0(+0) | 0(+0) |
| lvgl/src/draw/lv_img_decoder.c.obj | 1846(+1846) | 0(+0) | 0(+0) |
| lvgl/src/extra/layouts | 5418(+5418) | 0(+0) | 40(+40) |
| lvgl/src/extra/lv_extra.c.obj | 14(+14) | 0(+0) | 0(+0) |
| lvgl/src/extra/themes | 4926(+4926) | 0(+0) | 106(+106) |
| lvgl/src/extra/widgets | 4196(+4196) | 0(+0) | 2(+2) |
| lvgl/src/font/lv_font.c.obj | 52(+52) | 0(+0) | 0(+0) |
| lvgl/src/font/lv_font_fmt_txt.c.obj | 640(+640) | 0(+0) | 0(+0) |
| lvgl/src/font/lv_font_montserrat_10.c.obj | 0(+0) | 0(+0) | 8(+8) |
| lvgl/src/font/lv_font_montserrat_14.c.obj | 0(+0) | 0(+0) | 8(+8) |
| lvgl/src/font/lv_font_montserrat_18.c.obj | 0(+0) | 0(+0) | 8(+8) |
| lvgl/src/hal/lv_hal_disp.c.obj | 482(+482) | 0(+0) | 4(+4) |
| lvgl/src/hal/lv_hal_indev.c.obj | 190(+190) | 0(+0) | 0(+0) |
| lvgl/src/hal/lv_hal_tick.c.obj | 64(+64) | 0(+0) | 5(+5) |
| lvgl/src/misc/lv_anim.c.obj | 920(+920) | 0(+0) | 10(+10) |
| lvgl/src/misc/lv_area.c.obj | 988(+988) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_color.c.obj | 218(+218) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_fs.c.obj | 304(+304) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_gc.c.obj | 0(+0) | 0(+0) | 520(+520) |
| lvgl/src/misc/lv_ll.c.obj | 338(+338) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_math.c.obj | 350(+350) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_mem.c.obj | 1282(+1282) | 4(+4) | 32772(+32772) |
| lvgl/src/misc/lv_printf.c.obj | 1958(+1958) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_style.c.obj | 848(+848) | 2(+2) | 0(+0) |
| lvgl/src/misc/lv_style_gen.c.obj | 448(+448) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_timer.c.obj | 546(+546) | 0(+0) | 17(+17) |
| lvgl/src/misc/lv_tlsf.c.obj | 1316(+1316) | 0(+0) | 0(+0) |
| lvgl/src/misc/lv_txt.c.obj | 1362(+1362) | 24(+24) | 0(+0) |
| lvgl/src/misc/lv_utils.c.obj | 64(+64) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_arc.c.obj | 2878(+2878) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_bar.c.obj | 2004(+2004) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_btn.c.obj | 52(+52) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_btnmatrix.c.obj | 3790(+3790) | 28(+28) | 0(+0) |
| lvgl/src/widgets/lv_checkbox.c.obj | 908(+908) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_dropdown.c.obj | 2902(+2902) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_label.c.obj | 3048(+3048) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_line.c.obj | 390(+390) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_slider.c.obj | 1926(+1926) | 0(+0) | 0(+0) |
| lvgl/src/widgets/lv_switch.c.obj | 808(+808) | 0(+0) | 0(+0) |
| lvglDriver/LVGLDispDriverBase.cpp.obj | 46(+46) | 0(+0) | 0(+0) |
| lvglDriver/LVGLDispDriver_GC9A01.cpp.obj | 758(+758) | 0(+0) | 0(+0) |
| lvglDriver/LVGLInputDriverBase.cpp.obj | 30(+30) | 0(+0) | 0(+0) |
| lvglDriver/LVGLTouchDriverXPT2046.cpp.obj | 642(+642) | 0(+0) | 4(+4) |
| lvglDriver/TARGET_STM32F407VE_BLACK/LVGLDispDriverSTM32F407VE_BLACK.cpp.obj | 680(+680) | 0(+0) | 236(+236) |
| lvglDriver/TARGET_STM32F407VE_BLACK/LVGLTouchDriver_STM32F407VE_BLACK.cpp.obj | 120(+120) | 0(+0) | 240(+240) |
| lvglDriver/TARGET_STM32F407VE_BLACK/ili9341_fsmc.cpp.obj | 238(+238) | 0(+0) | 0(+0) |
| main.cpp.obj | 988(+988) | 0(+0) | 180(+180) |
| Subtotals | 144224(+144224) | 2616(+2616) | 43704(+43704) |
Total Static RAM memory (data + bss): 46320(+46320) bytes
Total Flash memory (text + data): 146840(+146840) bytes
I’m getting closer to the size problem with the static lib, with some help from here add target_include_directories for lvgl by JojoS62 · Pull Request #2713 · lvgl/lvgl · GitHub.
I see in the Ninja.build what user embeddedt suggested: the option -Os is missing. But I don’t why, is there a different rule for building libs?
for library:
FLAGS = -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -funsigned-char -fomit-frame-pointer -g3 -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
for Mbed project files:
FLAGS = -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-exceptions -ffunction-sections -fdata-sections -funsigned-char -fomit-frame-pointer -g3 -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -c -Os -Wno-unused-function
Success!
this works now:
add_subdirectory(${LIB_PATH}lvgl ${CMAKE_CURRENT_BINARY_DIR}/lvgl)
target_compile_options(lvgl PRIVATE -Os)
but I think the Mbed CMake should also use the same optimization for libraries, unless overwritten.
ah that’s good to hear!
Yes strange that lvgl is not using the same options.
Does it happen with other libs?
lvgl does not modify compiler flags. Maybe some problem with order of adding stuff in the projects CMakeLists? Haven’t tried with other lib yet.
I have opened an issue for this question, the Mbed cmake experts should know this.
Does the lvgl target link mbed? If not, you should not expect the mbed compiler flags to apply to lvgl.
That’s a good point! I would expect basic flags such as -0s to be applied to the whole project.
Its a third party lib, so it does not link to mbed-os. I have tested now with a simple example as in cmake: size of STATIC libraries is much larger than INTERFACE libs · Issue #15150 · ARMmbed/mbed-os · GitHub
Linking to mbed-os reveals the interface problem agin, every small lib which is even mbed independent (like in my example) will be blown up by pulling in full mbed-os. No fun.
Mbed needs to emit headers that libraries can use mbed functionality.
I can use lvgl now as static lib with adding the compile option, but for my lvglDriver I still need an interface lib because it needs mbed and lvgl. lvgl expects a configuration at a certain location in the application.
I have really choosen a weird example for learning cmake…
I didn’t mean that you should link it to mbed, your solution was the correct one. It makes sense to be able to compile different libraries with different compiler flags.
I have a similar setup in one my projects. I think the structure is ok.
Did you try LV_CONF_INCLUDE_SIMPLE?
Yeah but you learn how things shouldn’t be done, which is also good
no, but I know that it exists. But I want to wait what happens with this pending PR Allow CMake users to modify LV_LVGL_H_INCLUDE by higaski · Pull Request #2656 · lvgl/lvgl · GitHub
this looks like a smarter solution.
I have just read Jamies Cookbook for his mbed-cmake, this is something I would expect also for ARM Mbed to make the usage easier. I know CLI2 is still under development, and I just found also the discussions on github: ARMmbed/mbed-tools · Discussions · GitHub
I upvoted your question why there many places for discussion.
Thanks, proves my point