* Gmp test failure on armhf @ 2015-06-26 9:32 Andreas Enge 2015-06-28 20:39 ` Ludovic Courtès 0 siblings, 1 reply; 5+ messages in thread From: Andreas Enge @ 2015-06-26 9:32 UTC (permalink / raw To: guix-devel Hello, I installed guix via the binary tarball on my novena, then built a toolchain with guix and rebuilt the guix from git with it. So far, I am still using the binary tarball daemon. When running ./pre-inst-env guix build hello the build fails with a test failure in gmp. Before investigating further, I wonder if anybody else has had a similar problem? Or am I the only one using a recent git checkout of guix after the switch to a newer gcc version? Andreas ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gmp test failure on armhf 2015-06-26 9:32 Gmp test failure on armhf Andreas Enge @ 2015-06-28 20:39 ` Ludovic Courtès 2015-07-03 20:12 ` Andreas Enge 0 siblings, 1 reply; 5+ messages in thread From: Ludovic Courtès @ 2015-06-28 20:39 UTC (permalink / raw To: Andreas Enge; +Cc: guix-devel Andreas Enge <andreas@enge.fr> skribis: > When running > ./pre-inst-env guix build hello > the build fails with a test failure in gmp. Could you post the relevant excerpt of the build log, or ‘test-suite.log’? Ludo’. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gmp test failure on armhf 2015-06-28 20:39 ` Ludovic Courtès @ 2015-07-03 20:12 ` Andreas Enge 2015-07-04 7:08 ` Mark H Weaver 0 siblings, 1 reply; 5+ messages in thread From: Andreas Enge @ 2015-07-03 20:12 UTC (permalink / raw To: Ludovic Courtès; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 786 bytes --] On Sun, Jun 28, 2015 at 10:39:32PM +0200, Ludovic Courtès wrote: > Could you post the relevant excerpt of the build log, or > ‘test-suite.log’? Well, I tried to build it by hand, and it worked; then I tried again with a recent git version, and it also worked. Since I noticed a "FIXME" in the gmp package, I worked on that. The attached patch backports a fix to config.guess in the gmp trunk that correctly detects the neon architecture on multicore arm machines, instead of explicitly passing the build triplet. For testing purposes and your scrutiny, I added a new package gmp-arm; as indicated in the log message, my real intent is to modify the gmp package itself, which should be done in a new core-updates cycle. This would also be the occasion to update mpfr. Andreas [-- Attachment #2: 0001-gnu-gmp-Patch-detection-of-multicore-ARM-neon.patch --] [-- Type: text/plain, Size: 3072 bytes --] From 42af05881facd3eac843133b9aac49de36716003 Mon Sep 17 00:00:00 2001 From: Andreas Enge <privat@xobs-novena> Date: Fri, 3 Jul 2015 22:01:27 +0200 Subject: [PATCH] gnu: gmp: Patch detection of multicore ARM neon. * gnu/packages/patches/gmp-arm-neon.patch: New file. * gnu-system.am (dist_patch_DATA): Add it. * gnu/packages/multiprecision.scm (gmp)[source]: Use it. [arguments]: Drop the field. --- gnu-system.am | 1 + gnu/packages/multiprecision.scm | 16 ++++++++++++++++ gnu/packages/patches/gmp-arm-neon.patch | 16 ++++++++++++++++ 3 files changed, 33 insertions(+) create mode 100644 gnu/packages/patches/gmp-arm-neon.patch diff --git a/gnu-system.am b/gnu-system.am index a3c56a8..61385f2 100644 --- a/gnu-system.am +++ b/gnu-system.am @@ -447,6 +447,7 @@ dist_patch_DATA = \ gnu/packages/patches/glibc-ldd-x86_64.patch \ gnu/packages/patches/glibc-locales.patch \ gnu/packages/patches/gmp-arm-asm-nothumb.patch \ + gnu/packages/patches/gmp-arm-neon.patch \ gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch \ gnu/packages/patches/gobject-introspection-cc.patch \ gnu/packages/patches/gobject-introspection-girepository.patch \ diff --git a/gnu/packages/multiprecision.scm b/gnu/packages/multiprecision.scm index da52b2b..da257ed 100644 --- a/gnu/packages/multiprecision.scm +++ b/gnu/packages/multiprecision.scm @@ -66,6 +66,22 @@ cryptography and computational algebra.") (license lgpl3+) (home-page "http://gmplib.org/"))) +(define-public gmp-arm + (package (inherit gmp) + (name "gmp-arm") + (version "6.0.0a") + (source (origin + (method url-fetch) + (uri + (string-append "mirror://gnu/gmp/gmp-" + version ".tar.xz")) + (sha256 + (base32 + "0r5pp27cy7ch3dg5v0rsny8bib1zfvrza6027g2mp5f6v8pd6mli")) + (patches (list (search-patch "gmp-arm-asm-nothumb.patch") + (search-patch "gmp-arm-neon.patch"))))) + (arguments '()))) + (define-public mpfr (package (name "mpfr") diff --git a/gnu/packages/patches/gmp-arm-neon.patch b/gnu/packages/patches/gmp-arm-neon.patch new file mode 100644 index 0000000..6c267f5 --- /dev/null +++ b/gnu/packages/patches/gmp-arm-neon.patch @@ -0,0 +1,16 @@ +Patch to correctly detect the neon architecture for multicore machines; +taken from the trunk of the gmp mercurial repository. + +--- gmp-6.0.0.old/config.guess 2014-03-25 15:37:55.000000000 +0100 ++++ gmp-6.0.0.new/config.guess 2015-07-03 09:03:15.009942296 +0200 +@@ -199,8 +199,9 @@ + 0xc14) exact_cpu="armcortexr4";; # v7r + 0xc15) exact_cpu="armcortexr5";; # v7r + 0xc23) exact_cpu="armcortexm3";; # v7m ++ *) exact_cpu=$guess_cpu;; + esac +- exact_cpu="${exact_cpu}`sed -n 's;^Features.*\(neon\).*;\1;p' /proc/cpuinfo 2>/dev/null`" ++ exact_cpu="${exact_cpu}`sed -n 's;^Features.*\(neon\).*;\1;p' /proc/cpuinfo 2>/dev/null | head -n 1 2>/dev/null`" + ;; + + ia64*-*-*) -- 2.1.4 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Gmp test failure on armhf 2015-07-03 20:12 ` Andreas Enge @ 2015-07-04 7:08 ` Mark H Weaver 2015-07-04 8:15 ` Andreas Enge 0 siblings, 1 reply; 5+ messages in thread From: Mark H Weaver @ 2015-07-04 7:08 UTC (permalink / raw To: Andreas Enge; +Cc: guix-devel Andreas Enge <andreas@enge.fr> writes: > On Sun, Jun 28, 2015 at 10:39:32PM +0200, Ludovic Courtès wrote: >> Could you post the relevant excerpt of the build log, or >> ‘test-suite.log’? > > Well, I tried to build it by hand, and it worked; then I tried again with > a recent git version, and it also worked. > > Since I noticed a "FIXME" in the gmp package, I worked on that. The > attached patch backports a fix to config.guess in the gmp trunk that > correctly detects the neon architecture on multicore arm machines, instead > of explicitly passing the build triplet. We shouldn't be using config.guess anyway, because we shouldn't be compiling packages specialized for the build machine, at least not by default. A while back on IRC, Ludovic agreed to my proposal to pass --build to configure by default in gnu-build-system, a change to be made hopefully in the next core-updates cycle. After that, config.guess will not be used. As for NEON, I had originally followed Debian's armhf decision to compile code that doesn't require NEON support, but have since changed my mind about that. It seems that the Debian porters made that decision to support a couple of hardware devices that may have been important at the time, but that time has passed. I've since learned that NEON is a common target for modern highly optimized ARM assembly code, and that we should assume it as a baseline. This is another change that I think we should make in the next core-updates cycle. To give credit where credit is due: John Darrington chose to target NEON in his initial patches for Guix armhf. If we make these changes, then I think this patch is superfluous, right? Mark ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Gmp test failure on armhf 2015-07-04 7:08 ` Mark H Weaver @ 2015-07-04 8:15 ` Andreas Enge 0 siblings, 0 replies; 5+ messages in thread From: Andreas Enge @ 2015-07-04 8:15 UTC (permalink / raw To: Mark H Weaver; +Cc: guix-devel On Sat, Jul 04, 2015 at 03:08:14AM -0400, Mark H Weaver wrote: > A while back on IRC, Ludovic agreed to my proposal to pass --build to > configure by default in gnu-build-system, a change to be made hopefully > in the next core-updates cycle. After that, config.guess will not be > used. That sounds good to me and would indeed render my patch superfluous. > As for NEON, I had originally followed Debian's armhf decision to > compile code that doesn't require NEON support, but have since changed > my mind about that. It seems that the Debian porters made that decision > to support a couple of hardware devices that may have been important at > the time, but that time has passed. I've since learned that NEON is a > common target for modern highly optimized ARM assembly code, and that we > should assume it as a baseline. I agree with that. Andreas ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-07-04 8:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-06-26 9:32 Gmp test failure on armhf Andreas Enge 2015-06-28 20:39 ` Ludovic Courtès 2015-07-03 20:12 ` Andreas Enge 2015-07-04 7:08 ` Mark H Weaver 2015-07-04 8:15 ` Andreas Enge
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.