cmake: libc: minimal: Avoid linking against other libc implementations

[jonathonpenix]

The minimal libc is currently built as a zephyr_library and will be included in the final link line as such. However, the c_library property will still be set as "-lc" (for most linkers) and will be added to the link line. This effectively requires that a separate libc implementation be available in the toolchain and makes it possible to accidentally pull from the non-minimal libc.

This doesn't seem desirable, so try to prevent this by clearing the c_library property if we are using the minimal libc.

[jonathonpenix]

One other idea was to modify link_order_library in the various linker_libraries.cmake files to omit c if we're building with CONFIG_MINIMAL_LIBC. That did seem to work (and seems analogous to what was done for CONFIG_MINIMAL_LIBCPP), but this was a smaller change (and is somewhat similar to what is done for picolibc-as-a-module) so I ended up doing this instead--not sure if one is better than the other otherwise or if there is something entirely different that would be preferred!

[keith-packard]

You probably need to also change math_library and c++_library to make sure we don't mix other incompatible bits. This way we'll get a build error rather than a runtime error.

[tejlmand]

You probably need to also change math_library and c++_library to make sure we don't mix other incompatible bits.

actually, one intention in the new design is that you don't have to change all the definitions of the libraries, if all you want is to change the libs used and/or the order in which they are linked.
In such cases, the link_order_library property should be adjusted instead.

As the minimal libc is inside the whole-archive flags and it appears we don't want other bits, then I would suggest to do:

set_property(TARGET linker PROPERTY link_order_library "")

A future option is to change the minimal libc into a named library, and then link it specifically at the end, similar to what is done for picolibc, but that is a little more work, and thus I don't request it for this PR.

[jonathonpenix]

I'm not able to add reviewers, but please take a look @tejlmand too if possible!

[jonathonpenix]

Gentle ping

[mmahadevan108]

@jonathonpenix , this might be addressed as part of #80473 and #80472
@stephanosio, can you confirm

[jonathonpenix]

Thanks for pointing that out! Yep, I think the PRs you linked resolve this--I'll just close this one since I haven't gotten to the comments above and I think this would end up basically the same.

[tejlmand]

@jonathonpenix reopened this one.
Follows the intention of the new design closer than #80473 and #80472.

[jonathonpenix]

Apologies for pre-emptively closing this and for the slow responses on my end 😅

This was approved/merged, but just to double check: @keith-packard and @tejlmand do you think it is still worth addressing math_library/c++_library per the comments above?

I don't think there's a strict correctness issue here currently (math_library isn't added to link_order_library when minimal libc is selected and the various C++ lib options mostly either have a non-minimal-libc requirement in Kconfig or don't have c++_library set to anything--the one exception I think is when EXTERNAL_LIBCPP is selected, but I'm not really sure what the expectations are in that case), but it also makes sense to me that we might also want to clear math_library just as another safeguard, for example.

If it would still be worthwhile, I can try to add that as a follow-up PR.