#1014 Golang uses gcc to compile binaries but doesn't inherit CFLAGS.
Opened a year ago by jnovy. Modified 20 days ago
jnovy/packaging-committee golang  into  master

@@ -702,7 +702,7 @@ 


  Compilers used to build packages must honor the applicable compiler flags set in the system rpm configuration. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build.


- For C, {cpp}, and Fortran code, the xref:RPMMacros.adoc#build-flags-macros-and-variables[%\{optflags} macro] contains these flags.

+ For C, {cpp}, Fortran and Golang code, the xref:RPMMacros.adoc#build-flags-macros-and-variables[%\{optflags} macro] contains these flags. For Golang it is required to specify a separate CGO_CFLAGS variable in spec file in order to take effect.

  Overriding these flags for performance optimizations (for instance, -O3 instead of -O2) is generally discouraged. If you can present benchmarks that show a significant speedup for this particular code, this could be revisited on a case-by-case basis. Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so must be documented in the specfile.


  There are certain, security related flags that are commonly allowed. These flags may degrade performance slightly but the increased security can be worthwhile for some programs.

The CGO_CFLAGS variable needs to be used in order to do so. Not
specifying CGO_CFLAGS would lead to not using %optflags and hence
in unoptimized/unhardened code.

Signed-off-by: Jindrich Novy jnovy@redhat.com

@deparker ping, is this something that could be added to the %gobuild macro?

I'm reviewing old tickets and after reading this I'm not entirely sure whether we were waiting on one of the Go maintainers to make some change or if we need to do something else.

Not sure who maintains the Go macros right now, but it would be good to have this in %gobuild, so packagers don't need to do this manually (or continue forgetting to do so). Maybe @eclipseo knows? He's who maintains most Go packages right now, I think.