Segfault while compiling master for arm-unknown-linux-gnueabihf

[sunnystormy]

I get the following from my log every time I try to compile from master:

rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcore /home/***/GitRepos/rust/mk/target.mk:201: recipe for target 'arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/stamp.core' failed make: *** [arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/stamp.core] Segmentation fault (core dumped)

I'm compiling this on an ARMv7h Chromebook with 4 GB of RAM, so I don't know whether or not this is a bug, or an "Out Of Memory" issue.

[MagaTailor]

ARM7 was probably a typo so you could try using my stage0 snapshot for ARMv7.

If it works for you, this could be a repeat of issue #33483 which wasn't properly resolved as the OP was never heard from again.

[sunnystormy]

@petevine Thanks for pointing that out, I realize now that I was referencing ARM chips from 20 years ago! I corrected my OP to more accurately reflect its internals. I will investigate when I get my machine up and running again, as it turns out that I was also missing a swap partition on my ArchLinuxARM installation.

[MagaTailor]

The crash happens the moment rustc starts being used (single make job as everything depends on libcore) and even later at -j4 you won't see much more than 1GB memory usage on ARM.

[ghost]

I am experiencing the same issue on Raspberry Pi. The provided snapshot got me past the segfault, but then:

$ make
cfg: version 1.13.0-dev (413ada304 2016-08-18)
cfg: build triple arm-unknown-linux-gnueabihf
cfg: host triples arm-unknown-linux-gnueabihf
cfg: target triples arm-unknown-linux-gnueabihf
cfg: host for arm-unknown-linux-gnueabihf is arm
cfg: os for arm-unknown-linux-gnueabihf is unknown-linux-gnueabihf
cfg: no good valgrind for arm-unknown-linux-gnueabihf
cfg: using CC=gcc (CFG_CC)
cfg: disabling valgrind run-pass tests
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabi$
f/lib/libcore
src/libcore/intrinsics.rs:178:5: 178:37 error: unrecognized intrinsic function: 
`rustc_peek` [E0093]
src/libcore/intrinsics.rs:178     pub fn rustc_peek<T>(_: T) -> T;
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/libcore/intrinsics.rs:178:5: 178:37 help: run `rustc --explain E0093` to se$
 a detailed explanation
error: aborting due to previous error
make: *** [/home/alarm/rust/mk/target.mk:216: arm-unknown-linux-gnueabihf/stage$
/lib/rustlib/arm-unknown-linux-gnueabihf/lib/stamp.core] Error 101

[MagaTailor]

@yrnameer That's because you downloaded an outdated snapshot.
I happened to upload a new one a few days ago, it should be good for bootstrapping the current nightly.

[ghost]

I figured as much. I've located your build scripts & snapshot. Is there any information I can provide that would be helpful?

[MagaTailor]

You can try bootstrapping your own compiler using that latest snapshot (just add --enable-local-rust --local-rust-root=...) or use the workaround from the linked issue above to see if it helps.

edit:
You were already using a local snapshot, please ignore the parenthesised advice ;)

[ghost]

It's going to be a couple hours before I can report back.

for the record:

$ uname -a
Linux alarmpi 4.4.17-2-ARCH #1 SMP Tue Aug 16 19:17:53 MDT 2016 armv7l GNU/Linux

$ /usr/lib/libc.so.6 
GNU C Library (GNU libc) stable release version 2.24, by Roland McGrath et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 6.1.1 20160802.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
<https://github.com/archlinuxarm/PKGBUILDs/issues>.

[MagaTailor]

On Sat, 20 Aug 2016 11:51:07 -0700
yrnameer notifications@github.com wrote:

It's going to be a couple hours before I can report back.

Cool, I take it you're going to compile LLVM from scratch?

[ghost]

Yes, ran into a missing FileCheck while trying to use the local llvm. Enstead of troublshooting I just dropped the flag.

[MagaTailor]

Great, even though --disable-codegen-tests would have helped, it's better to eliminate all variables for now. Next time you should definitely save those 3.5hrs :)

[ghost]

make[2]: Leaving directory '/home/dev/src/rustc-nightly/arm-unknown-linux-gnueabihf/rt/libbacktrace'
make[1]: Leaving directory '/home/dev/src/rustc-nightly/arm-unknown-linux-gnueabihf/rt/libbacktrace'
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liblibc
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librand
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_unicode
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_bitflags
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liballoc_system
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libunwind
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/liballoc
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libcollections
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libpanic_abort
rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libpanic_unwind
error[E0522]: definition of an unknown language item: `eh_personality_catch`.
   --> src/libpanic_unwind/gcc.rs:284:1
    |
284 | pub unsafe extern "C" fn rust_eh_personality_catch(state: uw::_Unwind_State,
    | ^

error: aborting due to previous error

I was unable to deduce what the workaround was.

Just to clarify, the snapshot is 1.12.0-dev and I'm targeting 1.13.0-dev. I followed the quick start over at RustBuild_v7.

I suspect I'm doing something silly here. 😕

[MagaTailor]

Nope, you did really well :)

Even though a similarly dated snapshot worked for me on x86 a few days ago, due to this PR, the ARM version is already too new, unfortunately :(

Let me correct my evil ways by offering this one instead.
If you replace the stage0 binaries, the build should restart gracefully after make.

[ghost]

Okay, everything went pretty smooth after that. The compiler works.

I tried using the Cargo from dropbox, but I'm running into a lot of dependency mismatch. Unfortunately I'm not entirely sure how to go about bootrapping a new one. I've looked at some of the older ones in cargo-dist, but they all segfualt.

I threw the offical Jessie image on another SD card just to try it, and rustup worked like a charm.

Edit: however, I still very much want to see this work on Arch Linux Arm.

[MagaTailor]

Just satisfy the missing dependencies and then use that cargo binary to bootstrap yours with a simple cargo build --release. BTW, did the proposed workaround not work for your segfaulting binaries?

sudo patchelf --add-needed libpthread.so.0 $(which cargo)

[ghost]

I didn't see that proposed anywhere, so I must have just been looking at the wrong thread of discussion. I will give it a try later this afternoon.

The dependencies were a little trickier, for instance libcurl-gnutls.so.4 followed a different semantic versioning in Arch so I tried symlinking it, then there was armv7l-unknown-linux-gnueabihf-gcc instead of arm-linux-gnueabihf-gcc that was expected. I wasn't sure if this was just a naming convention, or perhaps i was targeting the wrong platform entirely... So I just had to take a break.

[MagaTailor]

Symlinking should be enough, but once you've patched the official cargo binary (most of that stuff is statically linked so any openssl vuln. require a new updated binary) you'll be set.

[ghost]

The workaround fixed rustc-nightly, but applying it to cargo-nightly did not.

[ghost]

In the case of dependencies, turns out I had a small typo and symlinking libcurl-gnutls.so.4.0.0 was all that was needed. Cargo is now building. 👍

[MagaTailor]

Cool, please mention the problem you had with patchelf in the other thread. Thanks.

[Mark-Simulacrum]

It looks like everything was resolved here, so I'm going to close, but please do let us know if that's incorrect and we'll reopen.