GNU bug report logs - #39400
Go retains a reference to GCC

Previous Next

Full log

Message #17 received at 39400 <at> debbugs.gnu.org (full text, mbox):

From: Sarah Morgensen <iskarian <at> mgsn.dev>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, 39400 <at> debbugs.gnu.org
Subject: Re: bug#39400: Go retains a reference to GCC
Date: Wed, 07 Jul 2021 18:54:29 -0700

Hi,

Ludovic Courtès <ludo <at> 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

--
Sarah

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.