[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33620: address@hidden: Re: Golang programs keeping references [gnu:
From: |
Leo Famulari |
Subject: |
bug#33620: address@hidden: Re: Golang programs keeping references [gnu: go: Update default to 1.11.]] |
Date: |
Thu, 14 Mar 2019 15:44:15 -0400 |
User-agent: |
Mutt/1.11.3 (2019-02-01) |
The issue of Go packages keeping references to all their Go-language is
inputs is resolved with commit e3900a4d64e4bf6f426809d6bff058e5a2ae9bc8.
This commit basically avoids bringing the store paths into the build
environment at all by symlinking them into a union directory in the
TMPDIR. This is a bit of a hack but it's actually more idiomatic in Go
to have all the inputs in a single directory ("workspace" in Go). The
previous technique of passing a list of directories in the GOPATH
variable is officially supported but is definitely a 2nd-class technique
in practice.
----- Forwarded message from Pierre Neidhardt <address@hidden> -----
> I've added this to Go's (build) function:
>
> --8<---------------cut here---------------start------------->8---
> "-asmflags=all=-trimpath=/gnu/store"
> "-gcflags=all=-trimpath=/gnu/store"
> --8<---------------cut here---------------end--------------->8---
>
> The resulting binary is indeed trimmed, but that's not enough: it seems that
> Guix detects the remaining part of the path as a store item and includes it in
> the list of requisites. Is this really how Guix works? It does not need the
> full path?
Not having read the reference scanner code carefully, I expect that it
ignores the '/gnu/store/' since this path is actually configurable.
> Regarding Boyer-Moore over the binary, we would have to apply the changes for
> all recursive Go libraries. Now is there a reliable way to detect what's a Go
> library and what is not? We don't want to patch non-Go libraries, right?
> (Let's not forget that there is CGo...)
In (guix build-system go), I'd like to construct of list of inputs that
use the go-build-system and pass this list to the biuld side. This would
be useful for other things, but could also be used to detect which
inputs are Go libraries.
> If we can't think of a way to detect a Go library, Boyer-Moore does not seem
> to
> be a solution either. And we might have to wait for Go 1.13...
Waiting for upstream is always the easiest way :)
But it would still be nice to have Boyer-Moore available in (guix build
utils) for whenever we want to use it. Or even in Guile itself...
signature.asc
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#33620: address@hidden: Re: Golang programs keeping references [gnu: go: Update default to 1.11.]],
Leo Famulari <=