cgo seems to force -Werror into all compilations of c code.

The -Werror in the runtime/cgo package only affects the C code in the runtime/cgo package. It is not adding -Werror to user C code. Are you seeing -Werror causing failures to building the Go standard library itself?

@cherrymui I have not, but here is another bug that has been marked as a duplicate and seems to show that -Werror is added to user code.

The build.log.xz from that bug seems to indicate that all -Werror are applied to the runtime/cgo package itself.

Ok, that makes sense.
If I set CGO_CFLAGS to some value, would that replace the CFLAGS that are being applied to this code? I have a pending proposal to do that.

If I set CGO_CFLAGS to some value, would that replace the CFLAGS that are being applied to this code?

Yes and no. CGO_CFLAGS will be added to the C compilations, but not replacing the existing flags. I don't think we document/guarantee the order of flags that are passed. So if you set CGO_CFLAGS=-Wno-error, it may or may not cancel that -Werror.

Just to add, from the build.log.xz, the -Werror doesn't seem to cause any compilation failures.

I realize it isn't causing any compilation errors, but I'm getting flagged by our distro's qa just because it is there. Their documentation suggests dropping it for releases and keeping it for development.
Can you give me a way to disable the adding of -Werror, maybe an environment variable or a command line switch that the make scripts can use?

I don't think we currently have such a way. One way that I can think of is to have a wrapper script for the C compiler that scans the flags and drops -Werror before invoking the actual C compiler, and set CC to the wrapper script.

Are you proposing we introduce a way to do that?

I'm not sure that would be a good way to do it since we already set CC, so I'm going to bring one of our toolchain guys into this bug.

@thesamesam What do you think?

Policy-wise, I understand that some people may not agree with using -Werror. But I also don't really understand why it is a problem if one wants their own code to be compiled with -Werror (not other's code), or in general how their own code should be compiled. Thanks.

The issue is it makes building Go (or something using Go, given this came up when building e.g. Podman) a pain when testing new compilers which may introduce new warnings. Those things may either not be appropriate to report to Go upstream (e.g. trying out an option which is unlikely to be suitable for widespread deployment) or need investigation first.

@cherrymui Do you have any thoughts on this?

Personally I don't have strong opinion about -Werror. But I think people frequently build Go with new versions of GCC and clang, so if a newer version of GCC or clang introduces new warnings, the failure is reported in a timely base. If you test a new version of GCC or clang and see such failures, you are also welcome to report. Or are you testing more customized C toolchains?

With CGO_ENABLED=1 and trying to build a darwin executable on Linux I get:

clang: error: argument unused during compilation: '-arch arm64' [-Werror,-Wunused-command-line-argument]

And setting CGO_CFLAGS="-Wno-error" does not override this, as the -Werror is added by go after that.

If you test a new version of GCC or clang and see such failures, you are also welcome to report. Or are you testing more customized C toolchains?

Sorry, I thought I'd answered this. Yeah, if it's simply a new default warning with GCC or Clang, we should report it and get it fixed in Go if appropriate, but if we're e.g. customising the toolchain to enable our own stuff by default, that becomes more problematic. It's also then a pain for keeping older Go versions working.

Not to miss the obvious, but I would expect that you could avoid the clang error with CGO_CFLAGS=-Wno-unused-command-line-argument or CGO_CFLAGS=-w.

That said, I think that we should always put CGO_CFLAGS last on the command line.