bug#39400: Go retains a reference to GCC

[Ludovic Courtès]

Hi,

Sarah Morgensen <iskarian@mgsn.dev> skribis:

> 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

Ah, I didn’t know about cgo (a helper for C bindings, right?).

I think it’s a case where “dynamic composition” (i.e., looking for gcc
in $PATH at run time) is preferable, because there are lots of
situations where gcc is not needed at all.

[...]

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

Sounds good to me.  (gcc-7.5.0-lib is always in the RUNPATH of
executables, we don’t have to worry about this one.)

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

What do you mean by “external linking” and “internal linking” in this
context?  (I know very little about Go.)

Thanks!

Ludo’.