bug#39400: Go retains a reference to GCC

[Sarah Morgensen]

Hello all,

(I have CC'd Tobias since we briefly discussed this on #guix recently.)

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> It seems that Go unduly retains a reference to GCC:
>
> $ guix size go
> store item                                                       total    self
> /gnu/store/g4rrz9rnr8ssbnj3gx3dmsxv4glll8nf-go-1.12.15             646.3   
> 355.9  55.1%
> /gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0              177.4   
> 107.2  16.6%
> [...]

This is still the case:

$ guix size go
store item                                                       total    self
/gnu/store/vvly7zgn981brb37v8y8a7f9psx7c6ay-go-1.16.5              570.0   
371.5  65.2%
/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0              178.5   
107.3  18.8%
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31              38.4    
36.7   6.4%
/gnu/store/01b4w3m6mp55y531kyi1g8shh722kwqm-gcc-7.5.0-lib           71.0    
32.6   5.7%
/gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32          88.0    
17.0   3.0%
/gnu/store/kl68v5mclwp511xgpsl2h1s9gmsdxpzh-tzdata-2021a             1.9     
1.9   0.3%
/gnu/store/mmhimfwmmidf09jw1plw3aw1g1zn2nkh-bash-static-5.0.16       1.6     
1.6   0.3%
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16     39.4     
1.0   0.2%
/gnu/store/g2s5jfkfd4k973wb58476b1bbv9zpm6m-zlib-1.2.11             38.6     
0.2   0.0%
/gnu/store/zfbbn61ij7w0bl4wbrwi87x5ghqx968c-net-base-5.3             0.0     
0.0   0.0%
total: 570.0 MiB

But... is the "baking-in" of (a particular version of) GCC a bad thing?
I am not sure either way.

Go invokes gcc when compiling with cgo, and cgo (or at least the usage
of standard libraries which use cgo) is getting fairly common. If we do
not provide a default gcc with Go, a plain "go build" will produce an
error if it encounters something which uses cgo and it can't find gcc:

$ go build
# runtime/cgo
cgo: exec gcc: exec: "gcc": executable file not found in $PATH

The user would then have to either install a gcc-toolchain, or figure
out that they must set CGO_ENABLED=0. From this perspective, it is more
convenient to have GCC baked-in for the average user, who likely has no
reason to want a different CC anyway.

On the other hand, currently GCC is baked-in to Go in two ways:

* CC is set to /gnu/store/...-gcc-7.5.0/bin/gcc
* Go is patched so that it adds /gnu/store/...-gcc-7.5.0-lib/lib as a
runpath when linking with cgo files

This means that even if the user provides a different CC, the
gcc-7.5.0-lib dir will also be in the runpath. I do not know if, or how
much, this would conflict with other gcc-lib runpaths.

I have experimented with a couple ways of removing the gcc-7.5.0 reference:

1. Simply set CC=gcc. This works to remove gcc-7.5.0 from references,
but we still get a gcc-7.5.0-lib runpath. We can't remove this runpath
completely, as anything using cgo-enabled parts of the standard library
require it, and Go does not save the library location anywhere.

2. Make Go require external linking for anything using cgo, which would
remove the need to patch internal linking at all. Some platforms do not
support internally linking cgo at all, so Go should have no trouble
handling this. It does break some tests which expect to be able to
internally link, but I have not yet found any actual packages it breaks.

My instinct says that removing the reference, and doing so via #2, is
the way to go, but I am just a newcomer to Guix. WDYT?

--
Sarah