makefiles: No --fatal-warnings for Cortex-M linker

[chrysn]

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

• On Debian sid, this now works:

$ make -C examples/hello-world TOOLCHAIN=clang BOARD=microbit-v2

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.

[riot-ci]

Murdock results

✔️ PASSED

c322e07 makefiles: No --fatal-warnings for Cortex-M linker

Success	Failures	Total	Runtime
2000	0	2000	06m:24s

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]

Do we still need this with #18845?

[chrysn]

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.

[maribu]

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.

[chrysn]

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.

[Teufelchen1]

Whats the conclusion here?

[chrysn]

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.)