--- Begin Message ---
|
Subject: |
[PATCH 1/2] gnu: gmp-boot: Fix build on powerpc64le-linux |
|
Date: |
Wed, 4 Aug 2021 15:34:54 -0300 |
Linux on powerpc64 used to run in big-endian mode only. When support for
little-endian mode was added around 2014, they took the opportunity to
update the ELF ABI. The new ABI is known as ELF ABI v2, and the old one
retroactively called ELF ABI v1.
GMP 4.3.2 was released in 2010, so its hand-optimized assembly code for
powerpc64 only support ELF ABI v1. This causes a build failure on
powerpc64le-linux, which can be fixed by passing a host triplet with the
“none” CPU type. This tells the configure script to use generic C code for
the build.
* gnu/packages/commencement.scm (gmp-boot)[arguments]{#:configure-flags}: Add
“--host=none-unknown-linux-gnu” for powerpc64le targets.
---
Hello,
This patch fixes the following build error on powerpc64le-linux (shown
below for one file, but happens on several):
ld: mpn/.libs/add_n.o: ABI version 1 is not compatible with ABI version 2 output
ld: failed to merge target specific data of file mpn/.libs/add_n.o
I started investigating the problem in core-udpates-frozen but the same
issue happens in master as well so I suggest comitting it there instead.
The patch applies cleanly to both branches.
Thanks,
Thiago
gnu/packages/commencement.scm | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index e7bd6cf002c7..ae3f07bc59ef 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -1840,7 +1840,23 @@ ac_cv_c_float_format='IEEE (little-endian)'
(uri (string-append "mirror://gnu/gmp/gmp-" version
".tar.gz"))
(sha256 (base32
-
"15rwq54fi3s11izas6g985y9jklm3xprfsmym3v1g6xr84bavqvv"))))))
+
"15rwq54fi3s11izas6g985y9jklm3xprfsmym3v1g6xr84bavqvv"))))
+ (arguments
+ (substitute-keyword-arguments (package-arguments gmp)
+ ((#:configure-flags gmp-configure-flags)
+ `(cons* ,@(if (string-prefix? "powerpc64le-" (or
(%current-target-system)
+ (%current-system)))
+ ;; The powerpc64 assembly code in this version of GMP
+ ;; only supports the ELF ABI v1 but powerpc64le uses ELF
+ ;; ABI v2, so use the generic C code instead. This is
+ ;; done by specifying the CPU type as “none”.
+ ;;
+ ;; According to the manual, “this will run quite slowly,
+ ;; but it should be portable and should at least make it
+ ;; possible to get something running if all else fails.”
+ '("--host=none-unknown-linux-gnu")
+ '())
+ ,gmp-configure-flags))))))
(define mpfr-boot
(package
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#49881: [PATCH] gnu: mpfr-boot: Use gmp-boot as a dependency |
|
Date: |
Fri, 13 Aug 2021 00:14:46 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi,
Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:
> Em quarta-feira, 11 de agosto de 2021, às 18:49:03 -03, Ludovic Courtès
> escreveu:
[...]
>> Indeed. However, it turns out that ‘gmp-boot’, ‘mpfr-boot’, and
>> ‘mpc-boot’ are not actually used as dependencies; we only ever use their
>> source.
>>
>> I propose to instead make that explicit with the patch below. WDYT?
>
> I think it’s a great solution! Much simpler than my patches for this issue
> and also 49880 and 49882. Thank you very much for working on it.
>
> I also confirmed that with your patch, ‘gmp-boot’, ‘mpfr-boot’, and ‘mpc-
> boot’ “build” correctly on powerpc64le-linux (not that it really matters),
> and they also “build” correctly on i686-linux. The latter system also
> builds ‘gcc-core-mesboot1’ correctly.
Awesome, pushed as b417dde293080184dae9098e408849a237903a84.
> Out of curiosity, why did the CI even try to build ‘gmp-boot’, ‘mpfr-boot’,
> and ‘mpc-boot’ on powerpc64le-linux? They’re not public packages, and
> moreover they are only dependencies of ‘gcc-core-mesboot1’ which is only
> relevant on i686-linux…
That comes from commit 37861f6c293d7ed1033050b2b0597885ba65186f. The
motivation was to ensure that substitutes for these intermediate
packages would be available on the ci.guix front-end node. Failing to
do that, Cuirass would not attempt fetch them from build nodes on the
front-end node.
Sorry that this caused a false alarm!
Thanks,
Ludo’.
--- End Message ---