build system: fix compilation with LLVM

[maribu]

Contribution description

• makefiles/cflags.inc.mk: add -z noexecstack to link flags
  • GCC on some platforms does need an executable stack to generate trampoline code, but use of nested functions is not allowed in RIOT's code base anyway.
• makefiles/libc: fix wchar_t size warnings on LLVM
  • The test for the requirement of disabling wchar_t size warnings assumed that $(CC) is used for linking, instead of $(LINK). With GCC $(LINK) and $(CC) happen to be (in most cases) identical, but with LLVM they are not. This results in issues with compiling with LLVM.

Testing procedure

No change in binaries and everything should still compile.

Issues/PRs references

Inspired by #18844

[riot-ci]

Murdock results

✔️ PASSED

0077e9a makefiles/libc: fix wchar_t size warnings on LLVM

Success	Failures	Total	Runtime
2000	0	2000	07m:17s

Artifacts

• Documentation preview

This only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now.

[benpicco]

Our msp430 toolchain is too old to know about -z noexecstack 😞

[chrysn]

Thanks, this also Closes: #18522.

On the topic of not having an executable stack, my assumptions here are that:

1. We may at some point use any present MMUs to enforce that, but doing that is out of scope for this PR.
2. If some code does need to use an executable stack (say, because a third party library is trampolining around, or something JITish is added), then they can still propose a global switch (eg. a stack_is_execuable pseudomodule) that would turn the explicit noexecstack into an explicit execstack and disables any of 1. when needed, but implementing that is also out of scope for here.

Do they align with your intentions for this PR?

[maribu]

Our msp430 toolchain is too old to know about -z noexecstack 😞

That's a pity. The msp430 toolchain is relatively straight forward to build...

[maribu]

2. If some code does need to use an executable stack (say, because a third party library is trampolining around, or something JITish is added), then they can still propose a global switch (eg. a stack_is_execuable pseudomodule) that would turn the explicit noexecstack into an explicit execstack and disables any of 1. when needed, but implementing that is also out of scope for here.

Adding a -z execstack add the end of the link facts should take preference over the -z noexecstack, so it should be possible to counter this if ever needed.

However, I don't think that this is too likely needed. E.g. the JIT support of WASM increases the resource requirements so significantly that it becomes challenging to fit the constrained memory of typical RIOT hardware. But it does remain a theoretical option, nonetheless.

[maribu]

Thx :)

[maribu]

This apparently needs a backport. Building rust fails in the release branch for me, but works in master. Cherry-picking this fixes the issue.

Also, we really do want LLVM support (even beside rust) in the release, don't we?

[maribu]

Backport provided in #18928