[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guix fails to build on aarch64
|
From: |
Pierre Langlois |
|
Subject: |
Re: guix fails to build on aarch64 |
|
Date: |
Tue, 04 Jan 2022 14:30:34 +0000 |
|
User-agent: |
mu4e 1.6.10; emacs 27.2 |
Hi there,
Akira Kyle <akira@akirakyle.com> writes:
> Ricardo Wurmus <rekado@elephly.net> writes:
>> > test-name: file-needed/recursive
>> > location:
>> > /tmp/guix-build-guix-1.3.0-14.2a621f1.drv-0/source/tests/gremlin.scm:70
>> > source:
>> …
>> > + (and (zero? (close-pipe pipe))
>> > + (lset= string=?
>> > + (pk 'truth ground-truth)
>> > + (pk 'needed needed)))))
>> > actual-value: #f
>> > result: FAIL
>
>> Did the logs not contain the values for truth and needed? That would
>> mean that the test already failed to close the pipe.
>
> I've been trying to debug failing guix tests on aarch64. At the end of
> logfile for the gremlin test suite there's the following which may be
> related to why the truth and needed values were not printed:
>
> a.out: stripping RUNPATH to
> ("/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/gcc/aarch64-unknown-linux-gnu/10.3.0/../../.."
> "/gnu/store/40lx91wz35qci25qzi9xfqvxwby85xha-profile/lib") (removed
> ("/foo" "/bar"))
> a.out: warning: RUNPATH contains bogus entries:
> ("/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib"
> "/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/gcc/aarch64-unknown-linux-gnu/10.3.0/../../.."
> "/gnu/store/40lx91wz35qci25qzi9xfqvxwby85xha-profile/lib")
> a.out: error: depends on 'libgcc_s.so.1', which cannot be found in RUNPATH ()
> WARNING: (test-gremlin): imported module (guix build utils) overrides
> core binding `delete'
I've also been trying to fix this test but without much luck. It
does look similar to this issue for ppc64 [0], where the `ldd/ld.so'
beaviour isn't the same as what the gremlin guile module does. However
the patch proposed there isn't fixing the issue for me either on
aarch64.
[0]: https://issues.guix.gnu.org/52940,
Maybe we can compare notes and a solution will come up :-). So the test
fails because 'truth', the result from `ldd', has ld-linux-aarch64.so
listed while 'needed', from the gremlin guile module doesn't:
--8<---------------cut here---------------start------------->8---
(truth ;; result from `ldd libguile.so'
("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1"
"/gnu/store/...-glibc-2.33/lib/ld-linux-aarch64.so.1" ;; This isn't
;; in gremlins
"/gnu/store/...-glibc-2.33/lib/libc.so.6"
"/gnu/store/...-glibc-2.33/lib/libcrypt.so.1"
"/gnu/store/...-glibc-2.33/lib/libdl.so.2"
"/gnu/store/...-glibc-2.33/lib/libm.so.6"
"/gnu/store/...-glibc-2.33/lib/libpthread.so.0"
"/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1"
"/gnu/store/...-libffi-3.3/lib/libffi.so.7"
"/gnu/store/...-libgc-8.0.4/lib/libgc.so.1"
"/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2"))
(needed ;; result from gremlin
("/gnu/store/...-gcc-10.3.0-lib/lib/libgcc_s.so.1"
"/gnu/store/...-glibc-2.33/lib/libc.so.6"
"/gnu/store/...-glibc-2.33/lib/libcrypt.so.1"
"/gnu/store/...-glibc-2.33/lib/libdl.so.2"
"/gnu/store/...-glibc-2.33/lib/libm.so.6"
"/gnu/store/...-glibc-2.33/lib/libpthread.so.0"
"/gnu/store/...-guile-3.0.7/lib/libguile-3.0.so.1"
"/gnu/store/...-libffi-3.3/lib/libffi.so.7"
"/gnu/store/...-libgc-8.0.4/lib/libgc.so.1"
"/gnu/store/...-libunistring-0.9.10/lib/libunistring.so.2"))
--8<---------------cut here---------------end--------------->8---
Digging a bit more I started comparing x86_64 and aarch64 binaries and
noticed that libguile.so didn't have the same dynamic section:
--8<---------------cut here---------------start------------->8---
# On aarch64:
$ objdump -x
/gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0
/gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0:
file format elf64-littleaarch64
...
Dynamic Section:
NEEDED libgc.so.1
NEEDED libpthread.so.0
NEEDED libffi.so.7
NEEDED libunistring.so.2
NEEDED libcrypt.so.1
NEEDED libdl.so.2
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
SONAME libguile-3.0.so.1
...
# On x86_64:
$ objdump -x
/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-3.0.7/lib/libguile-3.0.so.1.4.0
/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-3.0.7/lib/libguile-3.0.so.1.4.0:
file format elf64-x86-64
...
Dynamic Section:
NEEDED libgc.so.1
NEEDED libpthread.so.0
NEEDED libffi.so.7
NEEDED libunistring.so.2
NEEDED libcrypt.so.1
NEEDED libdl.so.2
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2 # ld-linux-<arch>.so is here
SONAME libguile-3.0.so.1
...
--8<---------------cut here---------------end--------------->8---
On aarch64, ld-linux-<arch> is missing. I'm not sure if this is an
issue with our aarch64 port or if that's OK. It's interesting though
that if you run `ldd' on libguile on aarch64, the dynamic linker is
added to the list, even though it's not in the dynamic section:
--8<---------------cut here---------------start------------->8---
# On aarch64
$ ldd
/gnu/store/pqw0c33k2h8n2snpchnyvx7w617kk31s-guile-3.0.7/lib/libguile-3.0.so.1.4.0
linux-vdso.so.1 (0x0000ffff96fab000)
libgc.so.1 =>
/gnu/store/1gkpbfxjx2sbchjhf19yjm4a8vkir0nm-libgc-8.0.4/lib/libgc.so.1
(0x0000ffff96d88000)
libpthread.so.0 =>
/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libpthread.so.0
(0x0000ffff96d59000)
libffi.so.7 =>
/gnu/store/hjirgm7pwmc2biqz6d0fc1ajr3ha4v14-libffi-3.3/lib/libffi.so.7
(0x0000ffff96d40000)
libunistring.so.2 =>
/gnu/store/4k552fq1p6q73mr9ww7g5y3m77p7cfbm-libunistring-0.9.10/lib/libunistring.so.2
(0x0000ffff96bb4000)
libcrypt.so.1 =>
/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libcrypt.so.1
(0x0000ffff96b6d000)
libdl.so.2 =>
/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libdl.so.2
(0x0000ffff96b59000)
libm.so.6 =>
/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libm.so.6
(0x0000ffff96ab0000)
libgcc_s.so.1 =>
/gnu/store/47snyrq6pq6896m9dysp2s5vx53m6x08-gcc-10.3.0-lib/lib/libgcc_s.so.1
(0x0000ffff96a8b000)
libc.so.6 =>
/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/libc.so.6
(0x0000ffff96917000)
/gnu/store/skfhr2f8b7jnnpiarrrcjn6qx0xzfw00-glibc-2.33/lib/ld-linux-aarch64.so.1
(0x0000ffff96f79000)
# ^
--8<---------------cut here---------------end--------------->8---
We could adapt the test to add the dynamic linker, emulating `ldd', but
I'm curious if anybody deeply familiar with ELF and dynamic linking
might have an idea what's going on.
>
> There are other tests failing as well and the full test-suite.log I
> posted here: https://issues.guix.gnu.org/52943
>
> I'm a newcomer to guix so I feel a bit out of my depth trying to debug
> these failures. I'd really like to be able to use guix as my daily
> driver but so far it's been difficult since my machine is aarch64!
Thanks for highlighting this issue! Hopefully we can get this fixed
soon.
Thanks,
Pierre
signature.asc
Description: PGP signature