From: Pierre Langlois <pierre.langlois@gmx.com>
To: Akira Kyle <akira@akirakyle.com>
Cc: guix-devel@gnu.org
Subject: Re: guix fails to build on aarch64
Date: Tue, 04 Jan 2022 14:30:34 +0000 [thread overview]
Message-ID: <87mtkbeeas.fsf@gmx.com> (raw)
In-Reply-To: <CAPWcbYHWVYh5O0otnhNcpMzG7084_77mUazmPLskfioG9=w5uw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8824 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 519 bytes --]
next prev parent reply other threads:[~2022-01-04 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 1:27 guix fails to build on aarch64 Akira Kyle
2022-01-04 14:30 ` Pierre Langlois [this message]
2022-01-09 4:45 ` Chris Marusich
-- strict thread matches above, loose matches on Subject: below --
2022-01-02 20:31 Akira Kyle
2021-12-16 19:57 Vagrant Cascadian
2021-12-17 0:16 ` Vagrant Cascadian
2021-12-17 8:59 ` Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mtkbeeas.fsf@gmx.com \
--to=pierre.langlois@gmx.com \
--cc=akira@akirakyle.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).