From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Craven Subject: Re: [PATCH 1/7] build-system: Add cargo build system. Date: Tue, 13 Dec 2016 19:07:17 +0100 Message-ID: References: <20160928151538.11679-1-david@craven.ch> <87shsccwpv.fsf@gnu.org> <87k2b9s3e5.fsf@wasp.i-did-not-set--mail-host-address--so-tickle-me> <87oa0lchl1.fsf@gnu.org> <877f73sqbc.fsf@gnu.org> 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]:37561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cGrV0-0003FU-GO for guix-devel@gnu.org; Tue, 13 Dec 2016 13:08:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cGrUx-0002zj-Aa for guix-devel@gnu.org; Tue, 13 Dec 2016 13:08:22 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:35205) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cGrUx-0002zW-4y for guix-devel@gnu.org; Tue, 13 Dec 2016 13:08:19 -0500 Received: by mail-qt0-f193.google.com with SMTP id m48so14674664qta.2 for ; Tue, 13 Dec 2016 10:08:18 -0800 (PST) In-Reply-To: <877f73sqbc.fsf@gnu.org> 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: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel > Hmm why is there a second one? =E2=80=98gnu-build-system=E2=80=99 alread= y provides gcc > and gcc:lib as implicit inputs, so maybe it=E2=80=99s just a matter of re= moving > =E2=80=98gcc=E2=80=99 from Rust=E2=80=99s =E2=80=98inputs=E2=80=99? So we do have an implicit gcc:lib package as an input. But I have to patche= lf the rustc binaries and libraries so I need a way to retrieve the gcc lib ou= tput. I can do (assoc-ref inputs "gcc") but how do I get a reference to the lib output? (assoc-ref* inputs "gcc" "lib") doesn't work... So I add ("gcc:lib" ,gcc "lib") explicitly to the inputs so that I can retrieve it. This results in slightly different versions being included. guix size rustc-bootstrap /gnu/store/fafzikyzhwbryqxxqsbsdkkq47rfrd8z-rustc-bootstrap-1.12.1 414.6 240.4 58.0% /gnu/store/y1g6991kxvdk4vxhsq07r5saww30v8dq-gcc-4.9.4 138.6 77.2 18.6% /gnu/store/a64w9dq219a8d9k4mfz76mnzph9wsvfj-zlib-1.2.8 61.3 0.4 0.1% /gnu/store/q4a1z2arssij8iq80i4k0zqallqlh2lv-gcc-4.9.4-lib 61.1 22.8 5.5% /gnu/store/cdi08kw7r6r684w8mk0xq0dkgpjhfpmd-gcc-4.9.4-lib 61.0 22.7 5.5% /gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0 50.7 5.4 1.3% /gnu/store/bm0gfw4jkw8gd0vpnnzrb6z0xncrbx3p-readline-7.0 45.3 1.3 0.3% /gnu/store/hdrli1v7q3107w842s7di8rid82xlfvl-ncurses-6.0 44.0 5.7 1.4% /gnu/store/vxdm2dqckv3yvwihr4hs6f886v6104az-zlib-1.2.8 38.6 0.4 0.1% /gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24 38.3 36.8 8.9% /gnu/store/rvgmixpmsq5lqr9qflhkm70kg7a4rys2-bash-static-4.4.0 1.4 1.4 0.3% total: 414.6 MiB I also don't know why there are two zlib's in there. guix gc --referrers /gnu/store/vxdm2dqckv3yvwihr4hs6f886v6104az-zlib-1.2.8 /gnu/store/vxdm2dqckv3yvwihr4hs6f886v6104az-zlib-1.2.8 /gnu/store/y1g6991kxvdk4vxhsq07r5saww30v8dq-gcc-4.9.4 guix gc --referrers /gnu/store/q4a1z2arssij8iq80i4k0zqallqlh2lv-gcc-4.9.4-l= ib /gnu/store/59fld0ah99fn7fc5vfsn51dm4b7x401g-clang-3.8.1 /gnu/store/d5vl2fljy7vlhz51yccw8y76yw8rzjrc-cargo-bootstrap-0.13.0 /gnu/store/fafzikyzhwbryqxxqsbsdkkq47rfrd8z-rustc-bootstrap-1.12.1 /gnu/store/q4a1z2arssij8iq80i4k0zqallqlh2lv-gcc-4.9.4-lib Maybe it doesn't matter too much, I was just curious that's all :) > When you do =E2=80=98guix build rust -s i686-linux=E2=80=99, you get 32-b= it packages. > Is that enough or am I missing something? The problem here is that we are patching precompiled binaries for i686 to g= et them to run with guix. So I need to get a reference to a 32-bit glibc from within the package definition. I think that we'd have to --enable-mult= ilib. I don't know if we can make it a separate output and how we can prevent it from being added to %final-inputs by default. And then we need a way of obtaining it from within a package definition which amounts to the same problem as with gcc:lib.