-
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
makefiles: No --fatal-warnings for Cortex-M linker #18843
Conversation
Contributes-To: RIOT-OS#18522
Murdock results✔️ PASSED c322e07 makefiles: No --fatal-warnings for Cortex-M linker
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. |
Do we still need this with #18845? |
It's not essential to get anything to build. I still think it's a good
idea, because #18845 showed that linker warnings can really be just
warnings.
Our build system is generally quiet enough (and moreover, the linker
runs late) so that the warnings will still stand out.
|
I'm not convinced. Humans get easily trained to ignore warnings, if they pop up often. I think we, the RIOT core developers, should decided on whether to react on a warning or to dismiss it and not train application developers to ignore warnings. |
Generally, yes, warnings need to be used carefully. But what happens in #18893 (and I might have done as well if #18845 had not been provided) is that concrete warnings are explicitly silenced until they are properly fixed. But once the warning is silent, nobody bats an eye any more, and all seems fine until something more changes (eg. the "this is deprecated and will be an error in the next release" triggers), and then things are broken just again, and possibly more subtly, because the warning kept being ignored. We don't have build options that distinguish "a RIOT core developer is building it, show them warnings" and "hide warnings the devs deemed safe" (but are they really?), and I'm glad of that, because RIOT is a community project, and a drive-by contributor might have the right context none of the regulars currently has. Both regulars and occasional users can be prone to ignoring warnings, but things can break either way, and if there are warnings to be read at least one stands a chance of finding them in the logs. |
Whats the conclusion here? |
I think the conclusion is just to be more careful when silencing warnings that are otherwise fatal (because that can hide real problems), and otherwise leave things as is here, and tolerate that at some point things may break again due to a tooling upgrade and we have to fix them in some way (eg. by silencing the warning for a short fix and then keeping a very active issue to fix it properly soonish.) |
Contribution description
The linker flag --fatal-warnings was added in #3120 on the premise that linker warnings result in broken binaries.
Issue #18522 has more details on a concrete issue, but the present PR doesn't resolve that issue's root cause -- the issue just serves to illustrate that there are linker warnings that are really just that (warnings), and that the original premise was flawed and introduces failures where there needn't be any.
Testing procedure
Issues/PRs references
Reverts-Part-Of: #3120
Contributes-To: #18522
Original round of reviewers are the original contributor of that flag, and the last mainitainers who touched RIOT's linker scripts.