fix(freertos): set app_main as undefined even for linux target

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>

components/freertos/CMakeLists.txt

@@ -193,6 +193,11 @@ if(arch STREQUAL "linux")
         PROPERTIES COMPILE_OPTIONS
         "-Wno-strict-prototypes"
         )
+    if(APPLE)
+        target_link_libraries(${COMPONENT_LIB} INTERFACE "-u _app_main")
+    else()
+        target_link_libraries(${COMPONENT_LIB} INTERFACE "-u app_main")
+    endif()
 else()
     idf_component_get_property(COMPONENT_DIR freertos COMPONENT_DIR)