* 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.