-
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
Builds fail when different execstack options are around in objects #18522
Comments
This is not Rust specific -- I get the same issue when just using clang:
|
I'd consider removing the The flag was introduced in ba2d4a0 as part of #3120 -- @jnohlgard, where would you place this warning in the area between "there is a warning we should address but it's not broken yet" (but |
On OpenSUSE with
when building the helloworld example for native. The last warning also appears on Arch Linux with |
when building the helloworld example for native.
and anything for cortex boards?
|
Nope - neither on Arch nor on OpenSUSE. (Talking about the C helloworld example, not RUST.) |
Thanks, and just to check: you tested with TOOLCHAIN=llvm?
|
Nope, I tested with |
Contributes-To: RIOT-OS#18522
Contributes-To: RIOT-OS#18522
Something in the latest Debian sid updates (possibly some experimental packages, couldn't pin it down yet) makes builds fail if one of the objects involved has the .note.GNU-stack section present indicating a non-executable stack, and one of the objects has not. This is the case, typically, when Rust programs are built, as the Rust compiler apparently never needs an executable stack.
That'd generally not fatal (it just triggers a "ld: warning: lib_a-nano-msizer.o: missing .note.GNU-stack section implies executable stack" / "ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker"), but as we build with
-Wl,--fatal-warnings
, it becomes fatal as "collect2: error: ld returned 1 exit status".The best workaround I've found is to explicitly set
-z execstack
or-z noexecstack
(I'd need to look into the platforms to see what is actually the case, probably execstack, but if we don't use it and have an MPU, maybe make it noexec?); weirdly, both are accepted by the linker.If this is becoming common even on systems w/o experimental, this may need an urgent fix and backport. (But if so, it'd be a simple-to-test one as it wouldn't affect built binaries, just make the linker happy).
The text was updated successfully, but these errors were encountered: