From: "Ludovic Courtès" <ludo@gnu.org>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: guix-devel@gnu.org
Subject: Re: Golang programs keeping references [gnu: go: Update default to 1.11.]
Date: Fri, 14 Dec 2018 10:15:18 +0100 [thread overview]
Message-ID: <87ftv079ll.fsf@gnu.org> (raw)
In-Reply-To: <87a7lev8r8.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sun, 09 Dec 2018 19:46:03 +0100")
Hello!
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
> 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:
>
> "-asmflags=all=-trimpath=/gnu/store"
> "-gcflags=all=-trimpath=/gnu/store"
>
> 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?
No, the scanner just looks for the hash part of the store file name (see
‘scanForReferences’ in nix/libstore/references.cc).
How much of a problem is this though? Currently the set of references
looks reasonable:
--8<---------------cut here---------------start------------->8---
$ guix size go-ipfs
store item total self
/gnu/store/rm3cfgzd8iywjmsdcxf6gnwswm5za50x-go-ipfs-0.4.18 203.4 102.2 50.2%
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28 37.8 36.3 17.8%
/gnu/store/ypiv8dj4lkvsnm82s639h18l87frrh5g-gcc-6.5.0-lib 69.0 31.2 15.3%
/gnu/store/4sqps8dczv3g7rwbdibfz6rf5jlk7w90-gcc-5.5.0-lib 68.0 30.2 14.8%
/gnu/store/8g2wi0i5fgp0ylz99mckhprh25p1zgiv-tzdata-2018e 2.0 2.0 1.0%
/gnu/store/zzakf905mzla4csi1dn9qpcwmgbxj29b-bash-static-4.4.23 1.5 1.5 0.8%
/gnu/store/sj8m05bfj2902h67c4qkmvnzg2pjdgsv-net-base-5.3 0.0 0.0 0.0%
total: 203.4 MiB
--8<---------------cut here---------------end--------------->8---
Well OK we could do with a single gcc:lib :-), but other than that it
looks good.
Thoughts?
Ludo’.
next prev parent reply other threads:[~2018-12-14 9:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20181112093245.26230.94815@vcs0.savannah.gnu.org>
[not found] ` <20181112093246.AC1D620498@vcs0.savannah.gnu.org>
2018-11-12 17:29 ` Golang programs keeping references [gnu: go: Update default to 1.11.] Leo Famulari
2018-11-12 17:38 ` Pierre Neidhardt
2018-11-12 17:45 ` Leo Famulari
2018-11-12 17:48 ` Leo Famulari
2018-11-12 17:51 ` Leo Famulari
2018-12-09 18:46 ` Pierre Neidhardt
2018-12-14 9:15 ` Ludovic Courtès [this message]
2018-12-14 9:28 ` Pierre Neidhardt
2018-12-14 14:52 ` Ludovic Courtès
2018-12-14 15:20 ` Pierre Neidhardt
2018-12-15 18:10 ` Ludovic Courtès
2018-12-15 18:19 ` Pierre Neidhardt
2018-12-15 19:52 ` Leo Famulari
2018-12-15 19:57 ` Pierre Neidhardt
2018-12-15 19:55 ` Leo Famulari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftv079ll.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mail@ambrevar.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.