[bug#56051]

[bug#56051]

[Julien Lepiller]

This patch ensures that we don't record a reference to gcc-toolchain in
the result of `guix pull`.  With this, we save 150 MB of closure.

This is a patch to fix the first issue I found in
https://issues.guix.gnu.org/56030.

From f96742e204f6b98401f49f7d1066257d7355c873 Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Date: Sat, 18 Jun 2022 08:17:59 +0200
Subject: [PATCH] guix: self: Do not record reference to gcc-toolchain.

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(+)

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")))))
 
-- 
2.35.1

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Julien Lepiller]

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(+)

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")))))
 
-- 
2.36.1

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Julien Lepiller]

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?

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Julien Lepiller]

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?

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#56051: [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

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.

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#56051] [PATCH] guix: self: Do not record reference to gcc-toolchain.

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 314 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]