-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build system: fix compilation with LLVM #18845
Conversation
Murdock results✔️ PASSED 0077e9a makefiles/libc: fix wchar_t size warnings on LLVM
ArtifactsThis 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. |
Our msp430 toolchain is too old to know about |
Thanks, this also Closes: #18522. On the topic of not having an executable stack, my assumptions here are that:
Do they align with your intentions for this PR? |
That's a pity. The msp430 toolchain is relatively straight forward to build... |
Adding a 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. |
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.
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.
Thx :) |
This apparently needs a backport. Building rust fails in the release branch for me, but works in Also, we really do want LLVM support (even beside rust) in the release, don't we? |
Backport provided in #18928 |
Contribution description
-z noexecstack
to link flags$(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