[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39400: Go retains a reference to GCC

From: Sarah Morgensen
Subject: bug#39400: Go retains a reference to GCC
Date: Wed, 07 Jul 2021 18:54:29 -0700


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

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

Yes, cgo allows you to compile Go programs which interface with C, as
well as straight .c files.

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

I recently discovered that there is actually an issue with this
particular approach. If the user uses a newer gcc-toolchain, the
always-added gcc-7.5.0-lib shadows the newer libraries and newer symbols
are unavailable. See <https://issues.guix.gnu.org/36823>.

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

"external linking" => Go invokes gcc to link object files together
"internal linking" => Go does the linking itself


reply via email to

[Prev in Thread] Current Thread [Next in Thread]