Go compiler tries writing to the store

  • Done
  • quality assurance status badge
Details
2 participants
  • Sarah Morgensen
  • Leo Famulari
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 29 Jan 2018 22:39
(name . Peter Mikkelsen)(address . petermikkelsen10@gmail.com)(address . bug-guix@gnu.org)
20180129213905.GB8542@jasmine.lan
On Mon, Jan 29, 2018 at 10:50:10AM +0100, Peter Mikkelsen wrote:
Toggle quote (2 lines)
> Hi guix,

Hi, thanks for this report! I saw your brief conversation on #guix with
civodul. Unfortunately I've only been paying attention to packaging Go
software with Guix, so I didn't notice this issue.

Toggle quote (8 lines)
> For example, after setting the environment variable GOPATH to
> /home/peter/go, and creating a small hello world program in there, I
> would normally be able to run 'go install' in that folder, and the
> hello world binary would end up in my gopath. But on guixSD this is
> not the case, since it seems like 'go install' is trying to compile
> every single library provided by to go package itself, and that means
> writing to the store, which is not possible.

This is definitely a problem that we need to fix. However, I'm not sure
where to start...

I'll try debugging by checking if this works on Nix, and seeing what
they do differently.

Toggle quote (7 lines)
> So my question is: Is there a way to prevent 'go install' compiling
> things in the store, maybe by pre-compiling during installation of the
> go package? Or is there another preferred way to develop go
> applications on guix, since what i do now is 'go build', but that gets
> really slow with larger projects, at it recompiles everything
> everytime if i understand it right.

The compiler should never try to write to the store; something is wrong
with how we build it.

Changing the subject slightly, yes, `go build` always recompiles some
things:

In general, for Go libraries (they call them "packages"), `go build`
always discards the compiled objects. You have to use `go install` to
retain them and achieve a caching speedup.

For Go executable programs (called "commands"), `go build` does keep the
compiled executable.

To quote the docs [0]:

"Build compiles the packages named by the import paths, along with their
dependencies, but it does not install the results. [...] When compiling
multiple packages or a single non-main package, build compiles the
packages but discards the resulting object, serving only as a check that
the packages can be built."

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlpvlHkACgkQJkb6MLrK
fwgZ0w/+JAo3Hfy3D+VKjXYcg896DSk5suh0Tezp7hznMdTq64yeMlDiY2B9W4kR
ooBa4R5AOB08f80+zsXT2755IaSgRnPhVhlMQk3XECUGN4Gq93QHd6mDnfVQDP38
xV3hk1AEi7wblWwvvB4z5vPMPFH2MVPG5RCs8Y4Jl1myB1Mz7IHV6V5JEk4pEmaP
43hXUgUlLwiK6HNRbPw33TCjM9RLenE6hEeDxwJ49zwTHFI5pjPjCo/EI1af8iiz
2ZwVmLjPYgUm3rk4B4lywEDQAXoVkuElZ0TmY9LEnKqEaVSBJ/LCnj5ztYYmu0Ja
QeJMe6hqlADHcLXxVPVJfOIvMpdeeIBw8vYa1vlxvLYyLE1nzk2UubjLXU6QO6U7
HY4lNLblluVnJrsAm9P3nuK4K0myc6VkWQk5YAOoi/0cpt+Fp4nLWn9dDSwaLAv3
1fvsW6oDEknFGiupQn9w2wj9DOTNuj4Dhkuit5qKWfYH8JYq6MpwmsjBImEPERIG
pdNRCKz0HJAncs12eju2oz/ihIM3NAXdLdvRR5ELHbQk4OHOZwUgTWtc+DN1pVDC
/MJWfFZVr706tqdfJGXYT1npmOEd6g4Bo6XA21mOa2KszDW49A8vL/BK5ngyoHQJ
vytjUn7dPD8Mh67f/W+baXJx4MjkyqT/V8gGrMC1ebj219/EbWc=
=ZVLo
-----END PGP SIGNATURE-----


S
S
Sarah Morgensen wrote on 4 Jul 2021 00:35
(name . Leo Famulari)(address . leo@famulari.name)
86mtr3koud.fsf@mgsn.dev
Hello,

Looking through old Go bugs I found this. Is this still an issue for
anyone? I just tested with go@1.14 and go@1.16 and I got expected
behavior (binary was installed in ~/go/bin, since ~/go is the default
GOPATH).

Leo Famulari <leo@famulari.name> writes:

Toggle quote (15 lines)
> On Mon, Jan 29, 2018 at 10:50:10AM +0100, Peter Mikkelsen wrote:
>> Hi guix,
>
> Hi, thanks for this report! I saw your brief conversation on #guix with
> civodul. Unfortunately I've only been paying attention to packaging Go
> software with Guix, so I didn't notice this issue.
>
>> For example, after setting the environment variable GOPATH to
>> /home/peter/go, and creating a small hello world program in there, I
>> would normally be able to run 'go install' in that folder, and the
>> hello world binary would end up in my gopath. But on guixSD this is
>> not the case, since it seems like 'go install' is trying to compile
>> every single library provided by to go package itself, and that means
>> writing to the store, which is not possible.

--
Sarah
S
S
Sarah Morgensen wrote on 25 Jul 2021 02:17
(name . Leo Famulari)(address . leo@famulari.name)
86mtqbp7q5.fsf@mgsn.dev
Closing this as it seems this is no longer an issue with the go versions
currently packaged.

Sarah Morgensen <iskarian@mgsn.dev> writes:

Toggle quote (26 lines)
> Hello,
>
> Looking through old Go bugs I found this. Is this still an issue for
> anyone? I just tested with go@1.14 and go@1.16 and I got expected
> behavior (binary was installed in ~/go/bin, since ~/go is the default
> GOPATH).
>
> Leo Famulari <leo@famulari.name> writes:
>
>> On Mon, Jan 29, 2018 at 10:50:10AM +0100, Peter Mikkelsen wrote:
>>> Hi guix,
>>
>> Hi, thanks for this report! I saw your brief conversation on #guix with
>> civodul. Unfortunately I've only been paying attention to packaging Go
>> software with Guix, so I didn't notice this issue.
>>
>>> For example, after setting the environment variable GOPATH to
>>> /home/peter/go, and creating a small hello world program in there, I
>>> would normally be able to run 'go install' in that folder, and the
>>> hello world binary would end up in my gopath. But on guixSD this is
>>> not the case, since it seems like 'go install' is trying to compile
>>> every single library provided by to go package itself, and that means
>>> writing to the store, which is not possible.
>
> --
> Sarah
Closed
?