From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Golang programs keeping references [gnu: go: Update default to 1.11.] Date: Fri, 14 Dec 2018 10:15:18 +0100 Message-ID: <87ftv079ll.fsf@gnu.org> References: <20181112093245.26230.94815@vcs0.savannah.gnu.org> <20181112093246.AC1D620498@vcs0.savannah.gnu.org> <20181112172925.GA8875@jasmine.lan> <87efbqb3gy.fsf@ambrevar.xyz> <20181112174820.GB12396@jasmine.lan> <20181112175102.GA12783@jasmine.lan> <87a7lev8r8.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXjZ4-0007iu-6e for guix-devel@gnu.org; Fri, 14 Dec 2018 04:15:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXjZ2-0001c1-5N for guix-devel@gnu.org; Fri, 14 Dec 2018 04:15:22 -0500 In-Reply-To: <87a7lev8r8.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sun, 09 Dec 2018 19:46:03 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: guix-devel@gnu.org Hello! Pierre Neidhardt skribis: > I've investigated the possible solutions to avoid including the paths int= o 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=3Dall=3D-trimpath=3D/gnu/store" > "-gcflags=3Dall=3D-trimpath=3D/gnu/store" > > The resulting binary is indeed trimmed, but that's not enough: it seems t= hat > 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 =E2=80=98scanForReferences=E2=80=99 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 s= elf /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=E2=80=99.