GNU bug report logs - #33620
Golang programs keeping references [gnu: go: Update default to 1.11.]

Previous Next

Package: guix;

Reported by: Leo Famulari <leo <at> famulari.name>

Date: Wed, 5 Dec 2018 02:22:01 UTC

Severity: normal

Merged with 33741

Done: Leo Famulari <leo <at> famulari.name>

Bug is archived. No further changes may be made.

Full log


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

From: Leo Famulari <leo <at> famulari.name>
To: 33620 <at> debbugs.gnu.org
Subject: [mail <at> ambrevar.xyz: Re: Golang programs keeping references [gnu: go:
 Update default to 1.11.]]
Date: Sat, 15 Dec 2018 14:54:57 -0500
[Message part 1 (text/plain, inline)]
----- Forwarded message from Pierre Neidhardt <mail <at> ambrevar.xyz> -----

Date: Sun, 09 Dec 2018 19:46:03 +0100
From: Pierre Neidhardt <mail <at> ambrevar.xyz>
To: Leo Famulari <leo <at> famulari.name>
Cc: guix-devel <at> gnu.org
Subject: Re: Golang programs keeping references [gnu: go: Update default to 1.11.]
User-agent: mu4e 1.0; emacs 26.1

I've investigated the possible solutions to avoid including the paths into the
binaries.

I've found this:

https://github.com/golang/go/issues/16860

It's still unresolved and only planned for Go 1.13.

In the meantime, I've played with the -trimpath option to see if I could get
something out of it.

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?

Go supports only one call to -trimpath, so we can't even set this to the Go
inputs.

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

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

-- 
Pierre Neidhardt
https://ambrevar.xyz/



----- End forwarded message -----
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 6 years and 71 days ago.

Previous Next


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