The 'app' library and additional application libraries created are linked differently

[SebastianBoe]

Users should be able to describe complex applications that are organized into a hierarchy of libraries with different build properties.

To this end, it must be documented and exemplified how to create and use new app CMake libraries.

The desired model for application libraries is that they be organized as pure CMakeLists.txt libraries that could in theory be copied verbatim from a CMake project. So, no reliance on Zephyr CMake extensions or conventions. This is believed to lower the barrier of entry for application developers as they do not have to learn about Zephyr's CMake model and can instead use the standard CMake API to describe their application.

But it is not clear how to achieve this goal. One problem relates to linking. In the zephyr model, libraries are --whole-archive'd together to resolve unresolved references. But in the CMake model libraries should instead be explicitly linked together. There exists build script code that is aware of the 'app' library and ensures that it is whole-archived, but there is no mechanism to ensure that extra application libraries are linked in (and it is not clear if it desirable to use whole-archive on these libraries).

[SebastianBoe]

Example of the problem in action:
SebastianBoe@fa49952

The above does build because app_lib is not whole-archived, this again causes symbols in the 'kernel' library to be omitted.

A temporary workaround/solution (not sure if this is a clean solution yet) is to use the CMake model and explicitly link 'app_lib' with the 'kernel' library, like so:

5b8619f

This ensures that the 'kernel' references that 'app_lib' is using are not dropped. But is there any way for the user to figure this out on his own?

[SebastianBoe]

Issue originally reported in: #5554 (comment)

@pboettch : Hi, any thoughts on this workaround? 5b8619f

[pboettch]

Sorry for getting back a little late. I will try your work-around as soon as I can, but it looks promising.

It seems (to be tested) that the whole-archive and start/end-group-stuff is not necessary when using LINK_INTERFACE_MULTIPLICITY .

I tried playing around with it in zephyr's CMakeLists.txt (and getting rid of the not very cmakely overriding of linker-flags) but I must have missed something.

If this works, it would enable this features without further kludges to the CMake-build-system of zephyr.

[SebastianBoe]

"It seems (to be tested) that the whole-archive and start/end-group-stuff is not necessary when using LINK_INTERFACE_MULTIPLICITY ."

When initially porting the build system from Kbuild to CMake I tried and failed to get rid of --whole-archive. I can't remember the details, but I remember using LINK_INTERFACE_MULTIPLICITY. So it is still an open question whether --whole-archive can be removed.

As an aside, if one eventually gets rid of --whole-archive one should make sure that the mechanism that replaces it is compatible with LTO.

[pboettch]

With LTO you mean real LTO or garbage-collection via gc-sections?

[SebastianBoe]

real LTO

[zephyrbot]

Hi @tejlmand,

This issue, marked as an Enhancement, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise.

Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.

@SebastianBoe you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.

Thanks!