[PATCH] gnu: Allow building toolchain with non-default libc.

  • Done
  • quality assurance status badge
Details
3 participants
  • Carl Dong
  • Ludovic Courtès
  • Marius Bakke
Owner
unassigned
Submitted by
Carl Dong
Severity
normal

Debbugs page

C
C
Carl Dong wrote on 23 Jun 2019 13:15
(address . guix-patches@gnu.org)(name . Carl Dong)(address . accounts@carldong.me)
fwHqadVUPH-92wbCcmXEdA_4oFs1qI2MdeQOVljG4DcOQDwq16MlQpcw0vaAqX1dwRSbrGA5Qej3MOCn_6vIj8G9FOk-CYMEVZezH1ysoG8=@carldong.me
From: Carl Dong <accounts@carldong.me>

* gnu/packages/base.scm (make-gcc-libc): Make public.
* gnu/packages/commencement.scm (make-gcc-toolchain): Add 'libc'
optional argument to specify using a non-default glibc package, also
make public.
---
gnu/packages/base.scm | 2 +-
gnu/packages/commencement.scm | 103 ++++++++++++++++++----------------
2 files changed, 55 insertions(+), 50 deletions(-)

Toggle diff (137 lines)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 15f35009a9..e40b40681b 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -1009,7 +1009,7 @@ with the Linux kernel.")
(("/bin/pwd") "pwd"))
#t))))))))
-(define (make-gcc-libc base-gcc libc)
+(define-public (make-gcc-libc base-gcc libc)
"Return a GCC that targets LIBC."
(package (inherit base-gcc)
(name (string-append (package-name base-gcc) "-"
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index a8ec677cee..13912f1352 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -54,7 +54,8 @@
#:use-module (srfi srfi-26)
#:use-module (ice-9 vlist)
#:use-module (ice-9 match)
- #:use-module (ice-9 regex))
+ #:use-module (ice-9 regex)
+ #:export (make-gcc-toolchain))
;;; Commentary:
;;;
@@ -1014,55 +1015,59 @@ COREUTILS-FINAL vs. COREUTILS, etc."
;;; GCC toolchain.
;;;
-(define (make-gcc-toolchain gcc)
+(define* (make-gcc-toolchain gcc
+ #:optional
+ (libc #f))
"Return a complete toolchain for GCC."
- (package
- (name "gcc-toolchain")
- (version (package-version gcc))
- (source #f)
- (build-system trivial-build-system)
- (arguments
- '(#:modules ((guix build union))
- #:builder (begin
- (use-modules (ice-9 match)
- (srfi srfi-26)
- (guix build union))
-
- (let ((out (assoc-ref %outputs "out")))
-
- (match %build-inputs
- (((names . directories) ...)
- (union-build out directories)))
-
- (union-build (assoc-ref %outputs "debug")
- (list (assoc-ref %build-inputs
- "libc-debug")))
- (union-build (assoc-ref %outputs "static")
- (list (assoc-ref %build-inputs
- "libc-static")))
- #t))))
-
- (native-search-paths (package-native-search-paths gcc))
- (search-paths (package-search-paths gcc))
-
- (license (package-license gcc))
- (synopsis "Complete GCC tool chain for C/C++ development")
- (description
- "This package provides a complete GCC tool chain for C/C++ development to
-be installed in user profiles. This includes GCC, as well as libc (headers
-and binaries, plus debugging symbols in the @code{debug} output), and Binutils.")
- (home-page "https://gcc.gnu.org/")
- (outputs '("out" "debug" "static"))
-
- ;; The main raison d'être of this "meta-package" is (1) to conveniently
- ;; install everything that we need, and (2) to make sure ld-wrapper comes
- ;; before Binutils' ld in the user's profile.
- (inputs `(("gcc" ,gcc)
- ("ld-wrapper" ,(car (assoc-ref %final-inputs "ld-wrapper")))
- ("binutils" ,binutils-final)
- ("libc" ,glibc-final)
- ("libc-debug" ,glibc-final "debug")
- ("libc-static" ,glibc-final "static")))))
+ (let ((gcc (if libc (make-gcc-libc gcc libc) gcc))
+ (libc (if libc libc gcc-final)))
+ (package
+ (name (string-append (package-name gcc) "-toolchain"))
+ (version (package-version gcc))
+ (source #f)
+ (build-system trivial-build-system)
+ (arguments
+ '(#:modules ((guix build union))
+ #:builder (begin
+ (use-modules (ice-9 match)
+ (srfi srfi-26)
+ (guix build union))
+
+ (let ((out (assoc-ref %outputs "out")))
+
+ (match %build-inputs
+ (((names . directories) ...)
+ (union-build out directories)))
+
+ (union-build (assoc-ref %outputs "debug")
+ (list (assoc-ref %build-inputs
+ "libc-debug")))
+ (union-build (assoc-ref %outputs "static")
+ (list (assoc-ref %build-inputs
+ "libc-static")))
+ #t))))
+
+ (native-search-paths (package-native-search-paths gcc))
+ (search-paths (package-search-paths gcc))
+
+ (license (package-license gcc))
+ (synopsis "Complete GCC tool chain for C/C++ development")
+ (description
+ "This package provides a complete GCC tool chain for C/C++ development to
+be installed in user profiles. This includes GCC, as well as libc (headers
+an d binaries, plus debugging symbols in the @code{debug} output), and Binutils.")
+ (home-page "https://gcc.gnu.org/")
+ (outputs '("out" "debug" "static"))
+
+ ;; The main raison d'être of this "meta-package" is (1) to conveniently
+ ;; install everything that we need, and (2) to make sure ld-wrapper comes
+ ;; before Binutils' ld in the user's profile.
+ (inputs `(("gcc" ,gcc)
+ ("ld-wrapper" ,(car (assoc-ref %final-inputs "ld-wrapper")))
+ ("binutils" ,binutils-final)
+ ("libc" ,libc)
+ ("libc-debug" ,libc "debug")
+ ("libc-static" ,libc "static"))))))
(define-public gcc-toolchain-4.8
(make-gcc-toolchain gcc-4.8))
--
2.22.0
M
M
Marius Bakke wrote on 5 Jul 2019 15:46
(name . Carl Dong)(address . accounts@carldong.me)
87y31cqeu7.fsf@devup.no
Carl Dong <contact@carldong.me> writes:

Toggle quote (7 lines)
> From: Carl Dong <accounts@carldong.me>
>
> * gnu/packages/base.scm (make-gcc-libc): Make public.
> * gnu/packages/commencement.scm (make-gcc-toolchain): Add 'libc'
> optional argument to specify using a non-default glibc package, also
> make public.

It would be easier to digest this patch if it came with an actual user
of this change. Right now it complicates a very simple procedure for no
apparent reason. Can you elaborate a bit on the use case?

Guix excels at creating bespoke toolchains like these. It is easy to
express this change as a new 'make-gcc-toolchain-with-custom-libc'
procedure. So I'm not sure if it's worth changing 'make-gcc-toolchain',
which serves a fairly specific use case.

I would expect any reasonably complex toolchain to need further tweaks,
and we cannot possibly support all such configuration inside
'make-gcc-toolchain'.

Does that make sense?

It does sound useful to make these procedures more generally accessible
however. Perhaps 'make-gcc-toolchain' could be implemented in terms of
a more generic 'make-toolchain' interface?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0f02AACgkQoqBt8qM6
VPpLQggA1RBXndQ0HJCeUdSwO03moa691jd6USDQLUmZ4XRHEPKa8MF+q4C+7sef
RegOezahQ2aIht5ze/Is13N4VFC+sK4jLtP3KjGab9HKwANKuNKMJy5GXAXDa7mJ
aHsz+eME2LsZoJ0r6ZRmKEpqUpW7ypUNjEk/MeqErij6r9OB/u8z6OZs9gguE4rs
yApllbnirW5HU6jYWJRBnJHu0A8ANWr/EJdsKLwyJHOFYZPfe+qpHoowDZqkVFkh
K3cgLMQIkq0pMbjVVkL3yeucvmNqr8lAECO+jozBfFeKCaTODCrkEF+qW8SsVi0x
aDlPRbXzRzvbf2QzehxLGMmq5YjNdQ==
=rCq1
-----END PGP SIGNATURE-----

C
C
Carl Dong wrote on 7 Jul 2019 07:42
(name . Marius Bakke)(address . mbakke@fastmail.com)(name . 36346@debbugs.gnu.org)(address . 36346@debbugs.gnu.org)
XSh8JydMVmKk7r7WAaJ3J-hdycb_Q8veLjOhopkAeF7W4qki242hKCiIkx8dc-Yo_P1U7wjsn_dxpdFT5-CSxxhCPQy226KfugUs6su9SBU=@carldong.me
Hi Marius!

Toggle quote (4 lines)
> It would be easier to digest this patch if it came with an actual user of this
> change. Right now it complicates a very simple procedure for no apparent
> reason. Can you elaborate a bit on the use case?

Ah! This change is motivated by the work I've been doing in shifting the Bitcoin
release process to a Guix-based one. The binaries we produce aim to be
compatible with GLIBC_2_11, and we have glibc compat wrappers
all the way up to 2.27 (since we need RISCV support). With Guix, I hope that we
don't have to keep updating compat wrappers anymore, and pin our toolchain glibc
version to a fixed one. See here for how I use this:

Toggle quote (12 lines)
> Guix excels at creating bespoke toolchains like these. It is easy to express
> this change as a new 'make-gcc-toolchain-with-custom-libc' procedure. So I'm
> not sure if it's worth changing 'make-gcc-toolchain', which serves a fairly
> specific use case.
>
> I would expect any reasonably complex toolchain to need further tweaks, and we
> cannot possibly support all such configuration inside 'make-gcc-toolchain'.
>
> It does sound useful to make these procedures more generally accessible
> however. Perhaps 'make-gcc-toolchain' could be implemented in terms of a more
> generic 'make-toolchain' interface?

That all sound like promising solutions. My thought process comes from porting
riscv64 to Guix, where I realized that I had to override the default gcc version
(riscv64 requires gcc 7.1), glibc version (2.27), and kernel headers version
(4.15). That makes me think that the sensible list of things to be overridable
for a toolchain would be those three, in case of future architectures. I've
submitted previous patches to cross-base.scm that added the ability to
parameterize these three, and this patch was simply doing the same for
gcc-toolchain.

Anyway, please let me know which approach you'd prefer, and I'd be very happy to
implement and change. :-)


Cheers,
Carl Dong
contact@carldong.me
"I fight for the users"
M
M
Marius Bakke wrote on 8 Jul 2019 08:34
(name . Carl Dong)(address . contact@carldong.me)(name . 36346@debbugs.gnu.org)(address . 36346@debbugs.gnu.org)
8736jgr14z.fsf@devup.no
Carl Dong <contact@carldong.me> writes:

Toggle quote (15 lines)
> Hi Marius!
>
>> It would be easier to digest this patch if it came with an actual user of this
>> change. Right now it complicates a very simple procedure for no apparent
>> reason. Can you elaborate a bit on the use case?
>
> Ah! This change is motivated by the work I've been doing in shifting the Bitcoin
> release process to a Guix-based one. The binaries we produce aim to be
> compatible with GLIBC_2_11, and we have glibc compat wrappers
> (https://github.com/bitcoin/bitcoin/blob/f373beebbcc0c7d1160e02dc638a00b3e6831d98/src/compat/glibc_compat.cpp)
> all the way up to 2.27 (since we need RISCV support). With Guix, I hope that we
> don't have to keep updating compat wrappers anymore, and pin our toolchain glibc
> version to a fixed one. See here for how I use this:
> https://github.com/bitcoin/bitcoin/blob/e8dd4da0b287e0fe252c99bb4a7cb26c2e947b71/contrib/guix/packages/gcc-bitcoin.scm#L91

I see, thanks for the links.

Toggle quote (24 lines)
>> Guix excels at creating bespoke toolchains like these. It is easy to express
>> this change as a new 'make-gcc-toolchain-with-custom-libc' procedure. So I'm
>> not sure if it's worth changing 'make-gcc-toolchain', which serves a fairly
>> specific use case.
>>
>> I would expect any reasonably complex toolchain to need further tweaks, and we
>> cannot possibly support all such configuration inside 'make-gcc-toolchain'.
>>
>> It does sound useful to make these procedures more generally accessible
>> however. Perhaps 'make-gcc-toolchain' could be implemented in terms of a more
>> generic 'make-toolchain' interface?
>
> That all sound like promising solutions. My thought process comes from porting
> riscv64 to Guix, where I realized that I had to override the default gcc version
> (riscv64 requires gcc 7.1), glibc version (2.27), and kernel headers version
> (4.15). That makes me think that the sensible list of things to be overridable
> for a toolchain would be those three, in case of future architectures. I've
> submitted previous patches to cross-base.scm that added the ability to
> parameterize these three, and this patch was simply doing the same for
> gcc-toolchain.
>
> Anyway, please let me know which approach you'd prefer, and I'd be very happy to
> implement and change. :-)

I feel better about this patch now that I've seen its uses. It would be
great if you could leave some comments at the top of the definition
about what the libc argument is for, and maybe even a usage example.

Otherwise it LGTM. Let's hold it for a couple of days in case others
have additional suggestions.

Thanks!
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0jYnwACgkQoqBt8qM6
VPqacQf/R/rjukMVyy+c8rpuxOPLBd4cGsg1AC8xSx1FspI2VFk3l2UjoX4s5ywC
N9C0DZ4B0bAY1lWD8aYX+ZD4/TbsaxbPQwTUdE9R9WJe8JgQ0/WhWM5JZhjUuHX/
HzkTl89HnKncYKl1LzLhAxGpqPvu9JuOA680comO8JcwJImk9BvPJP6fnJNvJK35
ETrruwvlWyHCW1GAOXzDBu1Uxbac0IxFWD8dI26wdFQENeluZxAp/ZrKk4b3e5M8
OYvpEvHNi5Q9hpv+yCy4T11uBWgsFHiSbIjiBqA4viEHR0C17JsxEJjyTft+bIcd
MYGKy2mjIwIm/VzHEAwSGz0bIKVgNw==
=frjb
-----END PGP SIGNATURE-----

C
C
Carl Dong wrote on 8 Jul 2019 12:41
[PATCH] gnu: Allow building toolchain with non-default libc.
(address . 36346@debbugs.gnu.org)(name . Carl Dong)(address . accounts@carldong.me)
4_kqCtHTlX-MONOFQC9zlsdzOvhHCH5UOLZF_9b2nJIdAA_kZltvFZRcpFNOX-Oj8UL7loc9DY13SOGeUsfpKiLj5wDGftA96g3-661mIG8=@carldong.me
From: Carl Dong <accounts@carldong.me>

Here's the updated patch, with the clarifications requested.

* gnu/packages/base.scm (make-gcc-libc): Make public.
* gnu/packages/commencement.scm (make-gcc-toolchain): Add 'libc'
optional argument to specify using a non-default glibc package, also
make public.
---
gnu/packages/base.scm | 2 +-
gnu/packages/commencement.scm | 111 +++++++++++++++++++---------------
2 files changed, 62 insertions(+), 51 deletions(-)

Toggle diff (144 lines)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 15f35009a9..e40b40681b 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -1009,7 +1009,7 @@ with the Linux kernel.")
(("/bin/pwd") "pwd"))
#t))))))))
-(define (make-gcc-libc base-gcc libc)
+(define-public (make-gcc-libc base-gcc libc)
"Return a GCC that targets LIBC."
(package (inherit base-gcc)
(name (string-append (package-name base-gcc) "-"
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index a8ec677cee..4a41e2abf3 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -54,7 +54,8 @@
#:use-module (srfi srfi-26)
#:use-module (ice-9 vlist)
#:use-module (ice-9 match)
- #:use-module (ice-9 regex))
+ #:use-module (ice-9 regex)
+ #:export (make-gcc-toolchain))
;;; Commentary:
;;;
@@ -1014,55 +1015,65 @@ COREUTILS-FINAL vs. COREUTILS, etc."
;;; GCC toolchain.
;;;
-(define (make-gcc-toolchain gcc)
- "Return a complete toolchain for GCC."
- (package
- (name "gcc-toolchain")
- (version (package-version gcc))
- (source #f)
- (build-system trivial-build-system)
- (arguments
- '(#:modules ((guix build union))
- #:builder (begin
- (use-modules (ice-9 match)
- (srfi srfi-26)
- (guix build union))
-
- (let ((out (assoc-ref %outputs "out")))
-
- (match %build-inputs
- (((names . directories) ...)
- (union-build out directories)))
-
- (union-build (assoc-ref %outputs "debug")
- (list (assoc-ref %build-inputs
- "libc-debug")))
- (union-build (assoc-ref %outputs "static")
- (list (assoc-ref %build-inputs
- "libc-static")))
- #t))))
-
- (native-search-paths (package-native-search-paths gcc))
- (search-paths (package-search-paths gcc))
-
- (license (package-license gcc))
- (synopsis "Complete GCC tool chain for C/C++ development")
- (description
- "This package provides a complete GCC tool chain for C/C++ development to
-be installed in user profiles. This includes GCC, as well as libc (headers
-and binaries, plus debugging symbols in the @code{debug} output), and Binutils.")
- (home-page "https://gcc.gnu.org/")
- (outputs '("out" "debug" "static"))
-
- ;; The main raison d'être of this "meta-package" is (1) to conveniently
- ;; install everything that we need, and (2) to make sure ld-wrapper comes
- ;; before Binutils' ld in the user's profile.
- (inputs `(("gcc" ,gcc)
- ("ld-wrapper" ,(car (assoc-ref %final-inputs "ld-wrapper")))
- ("binutils" ,binutils-final)
- ("libc" ,glibc-final)
- ("libc-debug" ,glibc-final "debug")
- ("libc-static" ,glibc-final "static")))))
+;; Using the following procedure, a gcc toolchain targeting glibc-2.27 can be
+;; instantiated like this:
+;;
+;; (define-public gcc-glibc-2.27-toolchain
+;; (make-gcc-toolchain gcc glibc-2.27))
+
+(define* (make-gcc-toolchain gcc
+ #:optional
+ (libc #f))
+ "Return a complete toolchain for GCC. If LIBC is specified, target that libc."
+ (let ((gcc (if libc (make-gcc-libc gcc libc) gcc))
+ (libc (if libc libc glibc-final)))
+ (package
+ (name (string-append (package-name gcc) "-toolchain"))
+ (version (package-version gcc))
+ (source #f)
+ (build-system trivial-build-system)
+ (arguments
+ '(#:modules ((guix build union))
+ #:builder (begin
+ (use-modules (ice-9 match)
+ (srfi srfi-26)
+ (guix build union))
+
+ (let ((out (assoc-ref %outputs "out")))
+
+ (match %build-inputs
+ (((names . directories) ...)
+ (union-build out directories)))
+
+ (union-build (assoc-ref %outputs "debug")
+ (list (assoc-ref %build-inputs
+ "libc-debug")))
+ (union-build (assoc-ref %outputs "static")
+ (list (assoc-ref %build-inputs
+ "libc-static")))
+ #t))))
+
+ (native-search-paths (package-native-search-paths gcc))
+ (search-paths (package-search-paths gcc))
+
+ (license (package-license gcc))
+ (synopsis "Complete GCC tool chain for C/C++ development")
+ (description
+ "This package provides a complete GCC tool chain for C/C++ development to
+be installed in user profiles. This includes GCC, as well as libc (headers
+an d binaries, plus debugging symbols in the @code{debug} output), and Binutils.")
+ (home-page "https://gcc.gnu.org/")
+ (outputs '("out" "debug" "static"))
+
+ ;; The main raison d'être of this "meta-package" is (1) to conveniently
+ ;; install everything that we need, and (2) to make sure ld-wrapper comes
+ ;; before Binutils' ld in the user's profile.
+ (inputs `(("gcc" ,gcc)
+ ("ld-wrapper" ,(car (assoc-ref %final-inputs "ld-wrapper")))
+ ("binutils" ,binutils-final)
+ ("libc" ,libc)
+ ("libc-debug" ,libc "debug")
+ ("libc-static" ,libc "static"))))))
(define-public gcc-toolchain-4.8
(make-gcc-toolchain gcc-4.8))
--
2.22.0
L
L
Ludovic Courtès wrote on 19 Jul 2019 01:01
control message for bug #36346
(address . control@debbugs.gnu.org)
87o91qe9mk.fsf@gnu.org
tags 36346 fixed
close 36346
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 36346@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 36346
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch