From: Mark H Weaver <mhw@netris.org>
To: Bone Baboon <bone.baboon@disroot.org>
Cc: 48239@debbugs.gnu.org
Subject: bug#48239: rust-1.19.0 build fails
Date: Fri, 07 May 2021 14:25:56 -0400 [thread overview]
Message-ID: <87mtt6l7sg.fsf@netris.org> (raw)
In-Reply-To: <87k0ocis5r.fsf@disroot.org>
Hi,
Bone Baboon <bone.baboon@disroot.org> writes:
> Mark H Weaver writes:
>> Are you aware of any relevant customizations to your kernel
>> configuration that might possibly be related to this?
>
> The system configuration includes:
>
> ```
> (kernel-arguments
> (append
> (list
> "nomodeset"
> "ipv6.disable=1")
> %default-kernel-arguments))
> ```
Thanks. Those don't look relevant to this issue.
>> It might be worth trying the build a second time. Occasionally we see
>> nondeterministic build failures in some packages, although I don't
>> recall seeing such failures in Rust.
>
> I tried again and got the same error.
Okay. I think the next step, if you're sufficiently motivated, is to
try to debug this problem yourself. I'd be glad to help, but
unfortunately I can't do it myself, since I'm unable to reproduce this
problem on my systems.
Here's the basic outline of how to proceed:
(1) First, you'll need the failed build directory in
/tmp/guix-build-rust-1.19.0.drv-0. If you've deleted it, recreate
it by running "guix build rust --keep-failed" and waiting for it to
fail. If it has a different name, rename it to have the name above.
(2) Launch a bash shell that you'll use to retry the failed command. In
that shell, first run "env -i $(which bash)" to clear most of the
existing environment variable settings, and then "source
/tmp/guix-build-rust-1.19.0.drv-0/environment-variables" to load the
ones that were in use during the build.
(3) Move to the appropriate directory and try re-running the failed
command (found near the end of the failed build log):
output/rustc-build/rustc -C \
linker=/gnu/store/afpgzln8860m6yfhxy6i8n9rywbp85cy-gcc-7.5.0/bin/gcc \
-Z force-unstable-if-unmarked -L output/target-libs \
src/libcore/lib.rs -o output/target-libs/libcore.rlib
If you still get SIGFPE, then try running that command again within GDB
and see if you can get a backtrace. Since GDB won't be in your PATH,
you'll need to launch it via it's absolute file name, which you can get
from another shell using "guix build gdb".
You'll run "/gnu/store/…-gdb-10.1/bin/gdb output/rustc-build/rustc" and
then within GDB: "run -C linker=/gnu/store/…-gcc-7.5.0/bin/gcc …" (the
entire command except for the "output/rustc-build/rustc").
Hopefully the SIGFPE will happen within GDB as well, returning you to
the GDB prompt. Then type "bt" to get a backtrace, and show it to us.
Some fiddling may be required to get a decent backtrace with full source
information, e.g. by running "dir DIRNAME" within GDB to add a directory
to the "source path" (where it searches for the source files).
Anyway, if we can figure out where the SIGFPE is happening, perhaps we
can find the underlying problem, or at least report it to the mrustc
developers.
Thanks,
Mark
--
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>.
next prev parent reply other threads:[~2021-05-07 18:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-05 14:05 bug#48239: rust-1.19.0 build fails Bone Baboon via Bug reports for GNU Guix
2021-05-05 19:36 ` Mark H Weaver
2021-05-06 1:10 ` Bone Baboon via Bug reports for GNU Guix
2021-05-07 18:25 ` Mark H Weaver [this message]
2021-05-13 17:10 ` Bone Baboon via Bug reports for GNU Guix
2021-05-07 1:21 ` Bone Baboon via Bug reports for GNU Guix
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=87mtt6l7sg.fsf@netris.org \
--to=mhw@netris.org \
--cc=48239@debbugs.gnu.org \
--cc=bone.baboon@disroot.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).