| Message ID | 20220303140558.29261-2-maxim.cournoyer@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Add sysbench. | 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 |
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
diff --git a/gnu/packages/c.scm b/gnu/packages/c.scm index e53a7c865f..613f3c504e 100644 --- a/gnu/packages/c.scm +++ b/gnu/packages/c.scm @@ -896,6 +896,45 @@ (define-public aws-c-mqtt (home-page "https://github.com/awslabs/aws-c-mqtt") (license license:asl2.0))) +(define-public ck + (package + (name "ck") + (version "0.7.1") + (source (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/concurrencykit/ck") + (commit version))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "020yzfpvymdc8lc44znlnxmxb8mvp42g4nb4p8k814klazqvwh0x")))) + (build-system gnu-build-system) + (arguments + (list + #:phases + #~(modify-phases %standard-phases + (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")))))))) + (home-page "https://github.com/concurrencykit/ck") + (synopsis "C library for concurrent systems") + (description "Concurrency Kit (@code{ck}) provides concurrency primitives, +safe memory reclamation mechanisms and non-blocking (including lock-free) data +structures designed to aid in the research, design and implementation of high +performance concurrent systems developed in C99+.") + (license (list license:bsd-2 ;everything except... + license:asl2.0)))) ;src/ck_hp.c + (define-public utf8-h ;; The latest tag is used as there is no release. (let ((commit "500d4ea9f4c3449e5243c088d8af8700f7189734")