[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39400: Go retains a reference to GCC
From: |
Ludovic Courtès |
Subject: |
bug#39400: Go retains a reference to GCC |
Date: |
Wed, 07 Jul 2021 23:49:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
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’.