mirror of
https://github.com/espressif/esp-idf.git
synced 2026-10-01 18:50:34 +03:00
Frantisek Hrbata
07cd7e407b
In cmakev1, the initial order of components linked to the executable is determined by the `__build_expand_requirements` function and stored as a list in the `BUILD_COMPONENT_ALIASES` build property. Later, the components from `BUILD_COMPONENT_ALIASES` are linked to the executable using `target_link_libraries`. The issue is that `BUILD_COMPONENT_ALIASES` contains components in a "reversed" order compared to how they would typically appear on the link command line. In other words, components (archives) deeper in the dependency chain are placed first. As a result, cmake has to repeat the archives in the link command more times than is actually necessary. This has the beneficial side effect of placing libfreertos.a before libmain.a, allowing the `app_main` symbol to be resolved. In cmakev2, there is no predefined order because it does not perform early evaluation. Instead, the entire link command is created based on actual component dependencies using `target_link_libraries`. Consequently, freertos must set the `app_main` symbols as undefined. This is already done for non-Linux targets, but it must also be done for the Linux target. Another issue arises with macOS, which mangles C symbols by prepending an underscore. We cannot use the same method as in `components/linux/assert_func.c` for `__assert_func`, so for macOS, `_app_main` is used. In the future, if more undefined symbols need to be added for the Linux target, we should consider introducing a helper. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>