Last week a build broke because there was space after the Wl, some-linker-option The Warning messages can't be very challenging to decipher.
Most importantly: Are the warnings show-stoppers? Not in part of my pay grade.
There is a pragma to ignore specific warnings. This is "#pragma GCC diagnostic ignore "some-compiler-warning" which is useful when dealing with several versions of the GCC compiler.
Yes, it happens.
> Most importantly: Are the warnings show-stoppers? Not in part of my pay grade.
The best places (code quality wise) I've ever worked were the strictest on compiler warnings. Turn on all warnings, turn on extra warnings, treat warnings as errors, and forbid disabling warnings via #pragma. The absolute worst was the one where compiling the software using the compiler's default warning level produced a deluge of 40,000 warnings, and the culture was to disable warnings when they became annoying (vs. you know, fixing them).
My philosophy: Compilers don't issue warnings for fun. Every one of them is a potential problem and they are almost always worth fixing.
I also adhere to this in my personal hobby projects, too. It can be challenging when integrating with third party libraries, where the library maintainer doesn't care as much. I once submitted a patch to an open source project I won't name here, which fixed a bunch of warnings that seem to be only present in macOS builds (XCode's defaults tend to be quite strict). The response was not to merge it because "I don't regularly do macOS builds, and besides, they're just warnings." Alright, bro, sorry I tried to help.