| Message ID | 20220618065810.30767-1-julien@lepiller.eu |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#56051] guix: self: Do not record reference to gcc-toolchain. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
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")))))