[bug#54235,2/3] gnu: Add ck.

* gnu/packages/c.scm (ck): New variable.
---
 gnu/packages/c.scm | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)
  

Maxim Cournoyer schreef op do 03-03-2022 om 09:05 [-0500]:
> +          (replace 'configure
> +            ;; ck uses a custom configure script that stumbles on
> +            ;; '--enable-fast-install'.
> +            (lambda* (#:key parallel-build? #:allow-other-keys)
> +              (invoke "./configure"
> +                      (string-append "--prefix=" #$output)
> +                      (string-append "--mandir=" #$output "/share/man")
> +                      "--use-cc-builtins"
> +                      (string-append "--cores="
> +                                     (if parallel-build?
> +                                         (number->string (parallel-job-count))
> +                                         "1"))))))))

For cross-compilation support, it seems that the CC environment
variable needs to be set (and possibly AR and LD as well).

Also, the configure script looks in /proc/cpuinfo for ‘address sizes’
and ‘VMA bits’, there might be some reproducibility and cross-
compilation concerns there.

The configure script enables SSE things by default (on x86-32).  I
don't know if that can be assumed in Guix.

Greetings,
Maxime.
  

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> Maxim Cournoyer schreef op do 03-03-2022 om 09:05 [-0500]:
>> +          (replace 'configure
>> +            ;; ck uses a custom configure script that stumbles on
>> +            ;; '--enable-fast-install'.
>> +            (lambda* (#:key parallel-build? #:allow-other-keys)
>> +              (invoke "./configure"
>> +                      (string-append "--prefix=" #$output)
>> +                      (string-append "--mandir=" #$output "/share/man")
>> +                      "--use-cc-builtins"
>> +                      (string-append "--cores="
>> +                                     (if parallel-build?
>> +                                         (number->string (parallel-job-count))
>> +                                         "1"))))))))
>
> For cross-compilation support, it seems that the CC environment
> variable needs to be set (and possibly AR and LD as well).

It seems to be handled alright as it is; at least I was able to build
with:

./pre-inst-env guix build --target=arm-linux-gnueabihf ck
[...]
done with offloaded '/gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv'
successfully built /gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv
/gnu/store/n6ipif548pxk0319kpchpxa7h5z6pzcm-ck-0.7.1

> Also, the configure script looks in /proc/cpuinfo for ‘address sizes’
> and ‘VMA bits’, there might be some reproducibility and cross-
> compilation concerns there.

I haven't seen nondetermism in the builds between x86_64 host of very
different architecture (Core 2 Duo from 2007 vs a recent Ryzen).

> The configure script enables SSE things by default (on x86-32).  I
> don't know if that can be assumed in Guix.

SSE was introduced with the Pentium III line in 1999.  I'd think that's
old enough to assume it's available for x86 machines.

Thanks for taking a look and paying attention to these tricky issues.
With my observations above, does it look good to you?

Thanks,

Maxim
  

Maxim Cournoyer schreef op ma 07-03-2022 om 13:57 [-0500]:
> It seems to be handled alright as it is; at least I was able to build
> with:
> 
> ./pre-inst-env guix build --target=arm-linux-gnueabihf ck
> [...]
> done with offloaded '/gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv'
> successfully built /gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv
> /gnu/store/n6ipif548pxk0319kpchpxa7h5z6pzcm-ck-0.7.1

Unfortunately, that is a rather unreliable check.
This only checks that 'ck' could be compiled, but it does not check
that 'ck' was actually compiled for arm-linux-gnueabihf instead of
(%current-system).  It might still be the case that 'gcc' is used
instead of '$TARGET-gcc'

Could you run 'file' against /gnu/store/[...]/bin/* to verify things?
On my x86-64-linux-gnu system, for a native binary, I get:

a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-
2.33/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped

I'm not sure what you would get for an arm-linux-gnueabihf but it
probably should not include '64-bit' or 'x86-64'.

Assuming you have QEMU emulation _disabled_, you can also try running
the binary on your (presumably non-arm) system and verify that it fails
to start.

Greetings,
Maxime.
  

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> Maxim Cournoyer schreef op ma 07-03-2022 om 13:57 [-0500]:
>> It seems to be handled alright as it is; at least I was able to build
>> with:
>> 
>> ./pre-inst-env guix build --target=arm-linux-gnueabihf ck
>> [...]
>> done with offloaded '/gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv'
>> successfully built /gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv
>> /gnu/store/n6ipif548pxk0319kpchpxa7h5z6pzcm-ck-0.7.1
>
> Unfortunately, that is a rather unreliable check.
> This only checks that 'ck' could be compiled, but it does not check
> that 'ck' was actually compiled for arm-linux-gnueabihf instead of
> (%current-system).  It might still be the case that 'gcc' is used
> instead of '$TARGET-gcc'
>
> Could you run 'file' against /gnu/store/[...]/bin/* to verify things?
> On my x86-64-linux-gnu system, for a native binary, I get:
>
> a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-
> 2.33/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
>
> I'm not sure what you would get for an arm-linux-gnueabihf but it
> probably should not include '64-bit' or 'x86-64'.

Good catch, you are right:

--8<---------------cut here---------------start------------->8---
$ file /gnu/store/n6ipif548pxk0319kpchpxa7h5z6pzcm-ck-0.7.1/lib/libck.so.0.7.1 
/gnu/store/n6ipif548pxk0319kpchpxa7h5z6pzcm-ck-0.7.1/lib/libck.so.0.7.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
--8<---------------cut here---------------end--------------->8---

I'll be sending a V2 once I've fixed cross-compilation.  Another -1 for
custom/borked configure script, eh!

Thanks,

Maxim
  

Hi Maxime,

Maxime Devos <maximedevos@telenet.be> writes:

> Maxim Cournoyer schreef op ma 07-03-2022 om 13:57 [-0500]:
>> It seems to be handled alright as it is; at least I was able to build
>> with:
>> 
>> ./pre-inst-env guix build --target=arm-linux-gnueabihf ck
>> [...]
>> done with offloaded '/gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv'
>> successfully built /gnu/store/m1gv4a1q9cv3ig9v4bymb9wd9l6g93y3-ck-0.7.1.drv
>> /gnu/store/n6ipif548pxk0319kpchpxa7h5z6pzcm-ck-0.7.1
>
> Unfortunately, that is a rather unreliable check.
> This only checks that 'ck' could be compiled, but it does not check
> that 'ck' was actually compiled for arm-linux-gnueabihf instead of
> (%current-system).  It might still be the case that 'gcc' is used
> instead of '$TARGET-gcc'
>
> Could you run 'file' against /gnu/store/[...]/bin/* to verify things?
> On my x86-64-linux-gnu system, for a native binary, I get:
>
> a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
> linked, interpreter /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-
> 2.33/lib/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
>
> I'm not sure what you would get for an arm-linux-gnueabihf but it
> probably should not include '64-bit' or 'x86-64'.
>
> Assuming you have QEMU emulation _disabled_, you can also try running
> the binary on your (presumably non-arm) system and verify that it fails
> to start.
>
> Greetings,
> Maxime.

I tried hard to have the custom configure script collaborating, but in
the end, it appears critically broken.  This is what I tried:

--8<---------------cut here---------------start------------->8---
1 file changed, 52 insertions(+), 9 deletions(-)
gnu/packages/c.scm | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++---------

modified   gnu/packages/c.scm
@@ -38,6 +38,7 @@ (define-module (gnu packages c)
   #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system trivial)
+  #:use-module (guix store)
   #:use-module (gnu packages)
   #:use-module (gnu packages bash)
   #:use-module (gnu packages bootstrap)
@@ -916,16 +917,58 @@ (define-public ck
       #~(modify-phases %standard-phases
           (replace 'configure
             ;; ck uses a custom configure script that stumbles on
-            ;; '--enable-fast-install'.
+            ;; '--enable-fast-install', among other things.
             (lambda* (#:key parallel-build? #:allow-other-keys)
-              (invoke "./configure"
-                      (string-append "--prefix=" #$output)
-                      (string-append "--mandir=" #$output "/share/man")
-                      "--use-cc-builtins"
-                      (string-append "--cores="
-                                     (if parallel-build?
-                                         (number->string (parallel-job-count))
-                                         "1"))))))))
+              ;; TODO: Move AR-FOR-TARGET and LD-FOR-TARGET to (guix utils).
+              (define* (ar-for-target #:optional (target #$(%current-target-system)))
+                (if target
+                    (string-append target "-ar")
+                    "ar"))
+              (define* (ld-for-target #:optional (target #$(%current-target-system)))
+                (if target
+                    (string-append target "-ld")
+                    "ld"))
+              (define (gnu-triplet->machine target)
+                (letrec-syntax
+                    ((matches (syntax-rules (=>)
+                                ((_ (target-prefix => machine) rest ...)
+                                 (if (string-prefix? target-prefix target)
+                                     machine
+                                     (matches rest ...)))
+                                ((_)
+                                 (error "unsupported target" target)))))
+                  ;; This basically reproduces the logic handling the
+                  ;; PLATFORM variable in the configure script.
+                  (matches ("x86_64"      => "x86_64")
+                           ("i586"        => "x86")
+                           ("i686"        => "x86")
+                           ("aarch64"     => "aarch64")
+                           ("arm"         => "arm")
+                           ("ppc64"       => "ppc64")
+                           ("ppc"         => "ppc")
+                           ("s390x"       => "s390x")
+                           ("sparc64"     => "sparcv9"))))
+              (define target-machine (and=> #$(%current-target-system)
+                                            gnu-triplet->machine))
+              ;; The custom configure script doesn't make cross-compilation
+              ;; adjustments itself, so manually set the archiver, compiler
+              ;; and linker.  Even then, it is still broken and doesn't
+              ;; actually build any binary (see:
+              ;; https://github.com/concurrencykit/ck/issues/191).
+              (setenv "AR" (ar-for-target))
+              (setenv "CC" #$(cc-for-target))
+              (setenv "LD" (ld-for-target))
+              (setenv "LDFLAGS" "")
+              (apply invoke "./configure"
+                     `(,@(if target-machine
+                             (list (string-append "--profile=" target-machine))
+                             '())
+                       ,(string-append "--prefix=" #$output)
+                       ,(string-append "--mandir=" #$output "/share/man")
+                       ,(string-append "--cores="
+                                       (if parallel-build?
+                                           (number->string (parallel-job-count))
+                                           "1")))))))))
     (home-page "https://github.com/concurrencykit/ck")
     (synopsis "C library for concurrent systems")
     (description "Concurrency Kit (@code{ck}) provides concurrency primitives,
--8<---------------cut here---------------end--------------->8---

But due to the test setting COMPILER failing, it doesn't set any
ALL_LIBS and thus doesn't build anything (see:
https://github.com/concurrencykit/ck/issues/191).

I also tried patching COMPILER to hard-code it to gcc and export
COMPILER to gcc, but that doesn't work too; it seems the ordering of the
logic in script is wrong.

I'd still keep the changes in, which will make life easier if/when
upstream fixes their script.

Thanks,

Maxim