Hi, Sarah Morgensen <iskar...@mgsn.dev> skribis:
> Ludovic Courtès <l...@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’.
