[PATCH] gnu: fix some issues cross-compiling glib

[PATCH] gnu: fix some issues cross-compiling glib

[John Darrington]

From: John Darrington <john@darrington.wattle.id.au>

* gnu/packages/glib.scm (glib) : Moved inputs to native-inputs,
  and change "inputs" to "%build-inputs"
---
 gnu/packages/glib.scm |   47 ++++++++++++++++++++++++++++-------------------
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index ac1b095..9fe016d 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -133,35 +133,44 @@ shared NFS home directories.")
               "bin"           ; glib-mkenums, gtester, etc.; depends on Python
               "doc"))         ; 20 MiB of GTK-Doc reference
    (inputs
-    `(("coreutils" ,coreutils)
-      ("libffi" ,libffi)
+    `(("libffi" ,libffi)
       ("zlib" ,zlib)
       ("tzdata" ,tzdata)))     ; for tests/gdatetime.c
+
    (native-inputs
     `(("gettext" ,gnu-gettext)
       ("dbus" ,dbus)                              ; for GDBus tests
+      ("coreutils" ,coreutils)
       ("pkg-config" ,pkg-config)
+      ;; The following ought to be achieved by (native-self-input #t).
+      ;; Unfortunately it seems to only set glib:out.  We want glib:bin
+      ,@(if (%current-target-system) 
+            `(("native-glib" ,glib "bin"))
+            '())
       ("python" ,python-wrapper)
       ("perl" ,perl)                              ; needed by GIO tests
       ("bash" ,bash)))
-   (arguments
-    '(#:phases (alist-cons-before
-                'build 'pre-build
-                (lambda* (#:key inputs outputs #:allow-other-keys)
-                  ;; For tests/gdatetime.c.
-                  (setenv "TZDIR"
-                          (string-append (assoc-ref inputs "tzdata")
-                                         "/share/zoneinfo"))
 
-                  ;; Some tests want write access there.
-                  (setenv "XDG_CACHE_HOME" (getcwd))
-
-                  (substitute* '("glib/gspawn.c"
-                                 "glib/tests/utils.c"
-                                 "tests/spawn-test.c")
-                    (("/bin/sh")
-                     (string-append (assoc-ref inputs "bash") "/bin/sh"))))
-                %standard-phases)
+   (arguments
+    `(#:phases 
+       (alist-cons-before
+        'build 'pre-build
+        (lambda* (#:key inputs outputs #:allow-other-keys)
+          ;; For tests/gdatetime.c.
+          (setenv "TZDIR"
+                  (string-append (assoc-ref inputs "tzdata")
+                                 "/share/zoneinfo"))
+          
+          ;; Some tests want write access there.
+          (setenv "XDG_CACHE_HOME" (getcwd))
+          
+          (substitute* '("glib/gspawn.c"
+                         "glib/tests/utils.c"
+                         "tests/spawn-test.c")
+            (("/bin/sh")
+             (string-append 
+              (assoc-ref %build-inputs "bash") "/bin/sh"))))
+        %standard-phases)
 
       ;; Note: `--docdir' and `--htmldir' are not honored, so work around it.
       #:configure-flags (list (string-append "--with-html-dir="
-- 
1.7.10.4

Re: [PATCH] gnu: fix some issues cross-compiling glib

[Ludovic Courtès]

John Darrington <jmd@gnu.org> skribis:

> From: John Darrington <john@darrington.wattle.id.au>
>
> * gnu/packages/glib.scm (glib) : Moved inputs to native-inputs,
>   and change "inputs" to "%build-inputs"

OK for the former, but why the latter?  In general I think it’s
stylistically better to refer to the ‘inputs’ argument.

Also, what about somehow grouping big-rebuild changes together?  I’m
slightly worried by the post-release chaos that might occur.  :-)
Maybe core-updates, or maybe a more specific branch for
cross-compilation fixes?

> +      ;; The following ought to be achieved by (native-self-input #t).
> +      ;; Unfortunately it seems to only set glib:out.  We want glib:bin

Missing period at end of sentence.

(And you found a bug!)

Thanks,
Ludo’.

Re: [PATCH] gnu: fix some issues cross-compiling glib

[John Darrington]

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

On Tue, Nov 18, 2014 at 09:36:10PM +0100, Ludovic Court??s wrote:
     John Darrington <jmd@gnu.org> skribis:
     
     > From: John Darrington <john@darrington.wattle.id.au>
     >
     > * gnu/packages/glib.scm (glib) : Moved inputs to native-inputs,
     >   and change "inputs" to "%build-inputs"
     
     OK for the former, but why the latter?  In general I think it???s
     stylistically better to refer to the ???inputs??? argument.

I don't know why,  but it fails to build with "inputs".  (assoc-ref "inputs" "bash")
returns #f  
     
     Also, what about somehow grouping big-rebuild changes together?  I???m
     slightly worried by the post-release chaos that might occur.  :-)
     Maybe core-updates, or maybe a more specific branch for
     cross-compilation fixes?

I can push it to core-updates if you like.  How big is big?  

     
-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] gnu: fix some issues cross-compiling glib

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> On Tue, Nov 18, 2014 at 09:36:10PM +0100, Ludovic Court??s wrote:
>      John Darrington <jmd@gnu.org> skribis:
>      
>      > From: John Darrington <john@darrington.wattle.id.au>
>      >
>      > * gnu/packages/glib.scm (glib) : Moved inputs to native-inputs,
>      >   and change "inputs" to "%build-inputs"
>      
>      OK for the former, but why the latter?  In general I think it???s
>      stylistically better to refer to the ???inputs??? argument.
>
> I don't know why,  but it fails to build with "inputs".  (assoc-ref "inputs" "bash")
> returns #f  

You probably need (assoc-ref (or native-inputs inputs) "bash"), meaning
you’ll refer to the native Bash both when compiling natively and when
cross-compiling (as done in ATLAS and OpenSSL.)

>      Also, what about somehow grouping big-rebuild changes together?  I???m
>      slightly worried by the post-release chaos that might occur.  :-)
>      Maybe core-updates, or maybe a more specific branch for
>      cross-compilation fixes?
>
> I can push it to core-updates if you like.  How big is big?  

core-updates no longer exists.  Perhaps let’s just make a
‘cross-compilation’ branch (or ‘arm’?) with all such changes.
Then we’ll arrange for Hydra to build that branch, and merge it once
it’s stable and mostly built.

WDYT?

Thanks,
Ludo’.

Re: [PATCH] gnu: fix some issues cross-compiling glib

[John Darrington]

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

On Wed, Nov 19, 2014 at 09:53:24AM +0100, Ludovic Court??s wrote:
     
     You probably need (assoc-ref (or native-inputs inputs) "bash"), meaning
     you???ll refer to the native Bash both when compiling natively and when
     cross-compiling (as done in ATLAS and OpenSSL.)

OK, I will try that.
     
     core-updates no longer exists.  Perhaps let???s just make a
     ???cross-compilation??? branch (or ???arm????) with all such changes.
     Then we???ll arrange for Hydra to build that branch, and merge it once
     it???s stable and mostly built.
     
     WDYT?

Ok.  Had you in mind to have this branch natively compiled for Arm, or cross-compiled?

If the former, then obviously the necessary hardware will be needed.  If the latter,
then there are still some obstacles to overcome before it'll work.

J'

     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] gnu: fix some issues cross-compiling glib

[Ludovic Courtès]

John Darrington <john@darrington.wattle.id.au> skribis:

> On Wed, Nov 19, 2014 at 09:53:24AM +0100, Ludovic Court??s wrote:

[...]

>      core-updates no longer exists.  Perhaps let???s just make a
>      ???cross-compilation??? branch (or ???arm????) with all such changes.
>      Then we???ll arrange for Hydra to build that branch, and merge it once
>      it???s stable and mostly built.
>      
>      WDYT?
>
> Ok.  Had you in mind to have this branch natively compiled for Arm, or cross-compiled?

Possibly the latter.  But my point was that this branch would collect
cross-compilation-related patches, or maybe ARM-related patches, which
seems to be what you’re working on currently.

Ludo’.