help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building gcc and xgcc's with non-default glibc


From: Carl Dong
Subject: Building gcc and xgcc's with non-default glibc
Date: Fri, 03 May 2019 13:31:17 +0000

Hi all,

I've been making good progress on Guix builds for bitcoin core. I've done a few
things that I'm not 100% sure I got right, so I wanted to share with you all to
ask for advice and it'll perhaps help others in the future.

1. Making a gcc with a different version of glibc than default

One of the things that I needed to do was to ensure that my gcc's were using
glibc 2.27 instead of whatever was the latest version. This is to ensure glibc
compatibility with older distro releases that we still support. I took at look
at procedures such as cross-gcc in cross-base.scm and this is what I came up
with in the end:

```guile
(define* (make-gcc-libc xgcc libc)
  (package (inherit xgcc)
           (name (string-append (package-name xgcc) "-"
                                (package-name libc) "-"
                                (package-version libc)))
           (arguments
            (substitute-keyword-arguments
             (ensure-keyword-arguments (package-arguments xgcc)
                                       '(#:implicit-inputs? #f))
             ((#:make-flags flags)
              `(let ((libc (assoc-ref %build-inputs "libc")))
                 ;; FLAGS_FOR_TARGET are needed for the target libraries to 
receive
                 ;; the -Bxxx for the startfiles.
                 (cons (string-append "FLAGS_FOR_TARGET=-B" libc "/lib")
                       ,flags)))))
           (native-inputs
            `(("libc" ,libc)
              ("libc:static" ,libc "static")
              ,@(append (package-inputs xgcc)
                        (alist-delete "libc:static"
                                      (alist-delete "libc" (%final-inputs))))))
           (inputs '())))

(define-public gcc-glibc-2.27
  (make-gcc-libc gcc glibc-2.27))
```

I am aware of the `package-input-rewriting` procedure, but when I experimented
with it, it doesn't seem to effectively change the `glibc` version.

Does this seem reasonable? Would this be something useful to be in the Guix tree
for others?

2. Making a cross-libc with a different version of glibc than default

I needed to do the same as in 1 for the cross compilers I constructed, so I
whipped up this quick patch.

```diff
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index bb3d6d916a..f207882988 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -421,14 +421,15 @@ target that libc."

(define* (cross-libc target
#:optional
+                     (xglibc glibc)
(xgcc (cross-gcc target))
(xbinutils (cross-binutils target))
(xheaders (cross-kernel-headers target)))
"Return a libc cross-built for TARGET, a GNU triplet.  Use XGCC and
XBINUTILS and the cross tool chain."
-  (if (cross-newlib? target)
-      (native-libc target)
-      (let ((libc glibc))
+  (if (cross-newlib? target #:xglibc xglibc)
+      (native-libc target #:xglibc xglibc)
+      (let ((libc xglibc))
(package (inherit libc)
(name (string-append "glibc-cross-" target))
(arguments
@@ -501,13 +502,17 @@ XBINUTILS and the cross tool chain."
,@(package-inputs libc)     ;FIXME: static-bash
,@(package-native-inputs libc)))))))

-(define (native-libc target)
+(define (native-libc target
+                     #:optional
+                     (xglibc glibc))
(if (target-mingw? target)
mingw-w64
-      glibc))
+      xglibc))

-(define (cross-newlib? target)
-  (not (eq? (native-libc target) glibc)))
+(define (cross-newlib? target
+                       #:optional
+                       (xglibc glibc))
+  (not (eq? (native-libc target) xglibc)))


;;; Concrete cross tool chains are instantiated like this:
```

Does this seem reasonable? Is there a cleaner way
to do the same? Would this be useful in the Guix tree?

Thanks you all in advance for your help!

Cheers,
Carl Dong
address@hidden
"I fight for the users"



reply via email to

[Prev in Thread] Current Thread [Next in Thread]