| Message ID | 20220618065810.30767-1-julien@lepiller.eu |
|---|---|
| State | New |
| Headers |
Return-Path: <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org> X-Original-To: patchwork@mira.cbaines.net Delivered-To: patchwork@mira.cbaines.net Received: by mira.cbaines.net (Postfix, from userid 113) id 6106227BBEA; Sat, 18 Jun 2022 07:59:27 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mira.cbaines.net X-Spam-Level: X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mira.cbaines.net (Postfix) with ESMTPS id 1FAD727BBE9 for <patchwork@mira.cbaines.net>; Sat, 18 Jun 2022 07:59:27 +0100 (BST) Received: from localhost ([::1]:34218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org>) id 1o2SQY-0005Av-7o for patchwork@mira.cbaines.net; Sat, 18 Jun 2022 02:59:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55480) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1o2SQA-00058m-Bx for guix-patches@gnu.org; Sat, 18 Jun 2022 02:59:09 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:53542) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1o2SQA-0000Ro-1v for guix-patches@gnu.org; Sat, 18 Jun 2022 02:59:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1o2SQA-0000vS-1N for guix-patches@gnu.org; Sat, 18 Jun 2022 02:59:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain. References: <20220618064632.29319-1-julien@lepiller.eu> In-Reply-To: <20220618064632.29319-1-julien@lepiller.eu> Resent-From: Julien Lepiller <julien@lepiller.eu> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org> Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 18 Jun 2022 06:59:01 +0000 Resent-Message-ID: <handler.56051.B56051.16555355023509@debbugs.gnu.org> Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56051 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: To: 56051@debbugs.gnu.org Received: via spool by 56051-submit@debbugs.gnu.org id=B56051.16555355023509 (code B ref 56051); Sat, 18 Jun 2022 06:59:01 +0000 Received: (at 56051) by debbugs.gnu.org; 18 Jun 2022 06:58:22 +0000 Received: from localhost ([127.0.0.1]:47439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>) id 1o2SPV-0000uX-Pe for submit@debbugs.gnu.org; Sat, 18 Jun 2022 02:58:21 -0400 Received: from lepiller.eu ([89.234.186.109]:40808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <julien@lepiller.eu>) id 1o2SPT-0000uN-H6 for 56051@debbugs.gnu.org; Sat, 18 Jun 2022 02:58:19 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id b9c7e2f1 for <56051@debbugs.gnu.org>; Sat, 18 Jun 2022 06:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=from:to :subject:date:message-id:mime-version:content-transfer-encoding; s=dkim; bh=0V9BHttU6csfAa3hJPzlr56Oy7TrBl7k2OIrAiEShr4=; b=D9iS hGTvdVOBoWk75EeKfDN1z9+PLs/nm3+u1b6mEgDjEXsf12DcJJEM045VGr1SB1AY YrMEbmJG22o2ZNdFmgVSSQoSVYfibej2i9DvOvTD0/QdbYTIZIC9pXzwUQ+ajy7g UAWCAHeN7yn6M+5zmVsT/H4WzyHAjsPtACaMNpkzkriLeZBq93UkPidJpOg/I7CO zUez5yFtw8RZ1CdWpOFSwRKZR202PQpgiH2swhCLu14c3VIGIlb2wcwihyHkzncR dsFDwc66O/5anAwSQE6Am7Yy4JzBuAm18cUotVBAcpvLW1T9YaA8EM4AP95zk6Tr WztqlGJeoZ1Cbr5u5Q== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id 90e73140 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO) for <56051@debbugs.gnu.org>; Sat, 18 Jun 2022 06:58:18 +0000 (UTC) From: Julien Lepiller <julien@lepiller.eu> Date: Sat, 18 Jun 2022 08:58:10 +0200 Message-Id: <20220618065810.30767-1-julien@lepiller.eu> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: <guix-patches.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-patches>, <mailto:guix-patches-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/guix-patches> List-Post: <mailto:guix-patches@gnu.org> List-Help: <mailto:guix-patches-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-patches>, <mailto:guix-patches-request@gnu.org?subject=subscribe> Errors-To: guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org Sender: "Guix-patches" <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org> X-getmail-retrieved-from-mailbox: Patches |
| Series |
[bug#56051] guix: self: Do not record reference to gcc-toolchain.
|
|
Commit Message
Julien Lepiller
June 18, 2022, 6:58 a.m. UTC
The ld-wrapper from gcc-toolchain records a reference to the library path through rpath, but this is not needed. By explicitely using rpath flags instead, we save 150 MB of closure. * guix/self.scm (quiet-guile): Do not record reference to gcc-toolchain. --- guix/self.scm | 2 ++ 1 file changed, 2 insertions(+)
Comments
Julien Lepiller schreef op za 18-06-2022 om 08:58 [+0200]:
> (setenv "LIBRARY_PATH" #$(file-append gcc "/lib"))
I'm wondering if is this line that is incorrect, given that the
'gcc:out' store item does not have a /lib subdirectory. Would removing
this line be sufficient?
Greetings,
Maxime.
On June 18, 2022 11:45:43 AM GMT+02:00, Maxime Devos <maximedevos@telenet.be> wrote: >Julien Lepiller schreef op za 18-06-2022 om 08:58 [+0200]: >> (setenv "LIBRARY_PATH" #$(file-append gcc "/lib")) > >I'm wondering if is this line that is incorrect, given that the >'gcc:out' store item does not have a /lib subdirectory. Would removing >this line be sufficient? > >Greetings, >Maxime. Removing this line I get a message that gcc can't find crt*.o. Remember that this gcc is actually gcc-toolchain. Another possibility is to explicitely use gcc, binutils, glibc and ld-wrapper. Thought this would be better?
Julien Lepiller schreef op za 18-06-2022 om 14:13 [+0200]: > On June 18, 2022 11:45:43 AM GMT+02:00, Maxime Devos <maximedevos@telenet.be> wrote: > > Julien Lepiller schreef op za 18-06-2022 om 08:58 [+0200]: > > > (setenv "LIBRARY_PATH" #$(file-append gcc "/lib")) > > > > I'm wondering if is this line that is incorrect, given that the > > 'gcc:out' store item does not have a /lib subdirectory. Would removing > > this line be sufficient? > > > > Greetings, > > Maxime. > > Removing this line I get a message that gcc can't find crt*.o. Which crt are these? crt1.o, crti.o, crtn.o (from glibc) or crtbegin.o, crtend.o, crtprec64.o, ... (from gcc)? > Another possibility is to explicitely use gcc, binutils, glibc and > ld-wrapper. Thought this would be better? FWIW, the <c-compiler> infrastructure in (guix scripts pack) does that, and the code in guix/self.scm has a comment: ;; XXX: Reuse <c-compiler> from (guix scripts pack) instead? though maybe (guix scripts pack) has the same reference-keeping problem ... Greetings, Maxime.
Le Sat, 18 Jun 2022 19:23:28 +0200, Maxime Devos <maximedevos@telenet.be> a écrit : > Julien Lepiller schreef op za 18-06-2022 om 14:13 [+0200]: > > On June 18, 2022 11:45:43 AM GMT+02:00, Maxime Devos > > <maximedevos@telenet.be> wrote: > > > Julien Lepiller schreef op za 18-06-2022 om 08:58 [+0200]: > > > > (setenv "LIBRARY_PATH" #$(file-append gcc "/lib")) > > > > > > I'm wondering if is this line that is incorrect, given that the > > > 'gcc:out' store item does not have a /lib subdirectory. Would > > > removing this line be sufficient? > > > > > > Greetings, > > > Maxime. > > > > Removing this line I get a message that gcc can't find crt*.o. > > Which crt are these? crt1.o, crti.o, crtn.o (from glibc) or > crtbegin.o, crtend.o, crtprec64.o, ... (from gcc)? crt1.o and friends, from glibc. I tried using glibc explicitely and setting LIBRARY_PATH to (file-append glibc "/lib") and it worked. > > > Another possibility is to explicitely use gcc, binutils, glibc and > > ld-wrapper. Thought this would be better? > > FWIW, the <c-compiler> infrastructure in (guix scripts pack) does > that, and the code in guix/self.scm has a comment: > > ;; XXX: Reuse <c-compiler> from (guix scripts pack) instead? > > though maybe (guix scripts pack) has the same reference-keeping > problem ... > > Greetings, > Maxime. Mh, I'm not sure how to do that. Do you mind if I push this patch, and leave using <c-compiler> to future work?
Julien Lepiller schreef op za 18-06-2022 om 19:53 [+0200]: > crt1.o and friends, from glibc. I tried using glibc explicitely and > setting LIBRARY_PATH to (file-append glibc "/lib") and it worked. > > > > > > Another possibility is to explicitely use gcc, binutils, glibc and > > > ld-wrapper. Thought this would be better? > > > > FWIW, the <c-compiler> infrastructure in (guix scripts pack) does > > that, and the code in guix/self.scm has a comment: > > > > ;; XXX: Reuse <c-compiler> from (guix scripts pack) instead? > > > > though maybe (guix scripts pack) has the same reference-keeping > > problem ... > > > > Greetings, > > Maxime. > > Mh, I'm not sure how to do that. Do you mind if I push this patch, and > leave using <c-compiler> to future work? Sure, but keep in mind this adds 'glibc' to the closure (IIUC, packages like 'hello' use a different glibc, from %final-inputs in (gnu packages commencement)), so maybe best use (canonical-package glibc) instead? (*) (*) IIUC, (guix self) isn't used from any package module, so no cycle problems, can be imported directly. Greetings, Maxime
Le Sat, 18 Jun 2022 21:08:18 +0200, Maxime Devos <maximedevos@telenet.be> a écrit : > Julien Lepiller schreef op za 18-06-2022 om 19:53 [+0200]: > > crt1.o and friends, from glibc. I tried using glibc explicitely and > > setting LIBRARY_PATH to (file-append glibc "/lib") and it worked. > > > > > > > > > Another possibility is to explicitely use gcc, binutils, glibc > > > > and ld-wrapper. Thought this would be better? > > > > > > FWIW, the <c-compiler> infrastructure in (guix scripts pack) does > > > that, and the code in guix/self.scm has a comment: > > > > > > ;; XXX: Reuse <c-compiler> from (guix scripts pack) instead? > > > > > > though maybe (guix scripts pack) has the same reference-keeping > > > problem ... > > > > > > Greetings, > > > Maxime. > > > > Mh, I'm not sure how to do that. Do you mind if I push this patch, > > and leave using <c-compiler> to future work? > > Sure, but keep in mind this adds 'glibc' to the closure (IIUC, > packages like 'hello' use a different glibc, from %final-inputs in > (gnu packages commencement)), so maybe best use (canonical-package > glibc) instead? (*) > > (*) IIUC, (guix self) isn't used from any package module, so no cycle > problems, can be imported directly. > > Greetings, > Maxime I didn't notice a different glibc. I think gcc-toolchain already uses that glibc from commencement.scm. It's also defined in commencement.scm. Pushed to master as 319b8331b2357e12ec9edb9665513c32bef56622.
Julien Lepiller schreef op za 18-06-2022 om 22:14 [+0200]: > I didn't notice a different glibc. I think gcc-toolchain already uses > that glibc from commencement.scm. It's also defined in > commencement.scm. OOps I misread your message and thought you were adding #$(file-append glibc "/lib") somewhere.
diff --git a/guix/self.scm b/guix/self.scm index 9a64051c32..36ada4d171 100644 --- a/guix/self.scm +++ b/guix/self.scm @@ -569,10 +569,12 @@ (define build (filter package? packages)))) ":")) (setenv "LIBRARY_PATH" #$(file-append gcc "/lib")) + (setenv "GUIX_LD_WRAPPER_DISABLE_RPATH" "1") (invoke "gcc" #$(local-file source) "-Wall" "-g0" "-O2" "-I" #$(file-append guile "/include/guile/" effective) "-L" #$(file-append guile "/lib") + "-Wl,-rpath" #$(file-append guile "/lib") #$(string-append "-lguile-" effective) "-o" (string-append #$output "/bin/guile")))))