GNU bug report logs - #48239
rust-1.19.0 build fails

Previous Next

Full log

View this message in rfc822 format

From: Mark H Weaver <mhw <at> netris.org>
To: Bone Baboon <bone.baboon <at> disroot.org>
Cc: 48239 <at> debbugs.gnu.org
Subject: bug#48239: rust-1.19.0 build fails
Date: Fri, 07 May 2021 14:25:56 -0400

Hi,

Bone Baboon <bone.baboon <at> 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>.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.