"failed to run cargo build" on powerpc64 when installing rust 1.19.0

[aperezbios]

After downloading the latest Rust release tarball, 1.19.0, running ./configure, and then make, I get the following, after a few tarballs are downloaded successfully:

aperez@debian-sid-ppc64:~/rust-1.19.0$ make -j4
downloading https://static.rust-lang.org/dist/2017-06-08/rust-std-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
######################################################################## 100.0%
extracting /home/aperez/rust-1.19.0/build/cache/2017-06-08/rust-std-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
downloading https://static.rust-lang.org/dist/2017-06-08/rustc-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
######################################################################## 100.0%
extracting /home/aperez/rust-1.19.0/build/cache/2017-06-08/rustc-1.18.0-powerpc64-unknown-linux-gnu.tar.gz
downloading https://static.rust-lang.org/dist/2017-06-08/cargo-0.19.0-powerpc64-unknown-linux-gnu.tar.gz
######################################################################## 100.0%
extracting /home/aperez/rust-1.19.0/build/cache/2017-06-08/cargo-0.19.0-powerpc64-unknown-linux-gnu.tar.gz
failed to run: /home/aperez/rust-1.19.0/build/powerpc64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/aperez/rust-1.19.0/src/bootstrap/Cargo.toml
Build completed unsuccessfully in 0:00:51
Makefile:24: recipe for target 'all' failed
make: *** [all] Error 1

[aperezbios]

When I manually run "/home/aperez/rust-1.19.0/build/powerpc64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path /home/aperez/rust-1.19.0/src/bootstrap/Cargo.toml" I get "illegal instruction"

[aperezbios]

This is on a quad-core, Book-E powerpc64 CPU (Freescale/NXP P5040), which does not support Altivec instructions. Could that be the problem here?

[cuviper]

My first guess would be #43052, but that gets a SIGSEGV, not SIGILL. Can you run it under gdb and see what and where the offending instruction is?

[infinity0]

It is easy to confirm whether or not it is #43052 by running ulimit -s unlimited beforehand. If it does not fix the problem, then it is not that bug.

[TheBlueMatt]

This appears to still be the case on latest stable/nightly installed by rustup even on POWER9 ie with full latest altivec support. Running cargo fails with Illegal Instruction. The debian packages work completely fine though.

[TheBlueMatt]

BT:

Program received signal SIGILL, Illegal instruction.
0x0000000100000004 in ?? ()
(gdb) bt
#0 0x0000000100000004 in ?? ()
#1 0x0000000100887170 in rand_pool_acquire_entropy ()
#2 0x0000000100886858 in rand_drbg_get_entropy ()
#3 0x000000010088415c in RAND_DRBG_instantiate ()
#4 0x00000001008854d8 in drbg_setup ()
#5 0x00000001008855f8 in do_rand_drbg_init_ossl_ ()
#6 0x00003ffff7f5ed48 in _pthread_once_slow (once_control=0x100cea7c8 <rand_drbg_init>,
init_routine=0x100885550 <do_rand_drbg_init_ossl>) at pthread_once.c:116
#7 0x00000001008a9d98 in CRYPTO_THREAD_run_once ()
#8 0x0000000100885a00 in RAND_DRBG_get0_public ()
#9 0x0000000100885ae8 in drbg_bytes ()
#10 0x0000000100886c00 in RAND_bytes ()
#11 0x00000001007d090c in SSL_CTX_new ()
#12 0x0000000100683188 in git_openssl_stream_global_init ()
#13 0x0000000100636494 in init_once ()
#14 0x00003ffff7f5ed48 in __pthread_once_slow (once_control=0x100ce83dc <_once_init>, init_routine=0x1006363c0 <init_once>)
at pthread_once.c:116
#15 0x0000000100636604 in git_libgit2_init ()
#16 0x000000010060fa10 in std::sync::once::Once::call_once::{{closure}} ()
#17 0x00000001009df574 in std::sync::once::Once::call_inner () at libstd/sync/once.rs:397
#18 0x000000010060f9b8 in libgit2_sys::init ()
#19 0x00000001005ff7e0 in git2::config::Config::open_default ()
#20 0x0000000100427bd0 in cargo::ops::registry::http_proxy ()
#21 0x0000000100425fdc in cargo::ops::registry::needs_custom_http_transport ()
#22 0x00000001000e8b18 in cargo::main ()
#23 0x00000001000de644 in std::rt::lang_start::{{closure}} ()
#24 0x00000001009ee4a4 in std::rt::lang_start_internal::{{closure}}::{{closure}} () at libstd/rt.rs:59
#25 std::sys_common::backtrace::__rust_begin_short_backtrace () at libstd/sys_common/backtrace.rs:136
#26 0x0000000100a04f6c in std::rt::lang_start_internal::{{closure}} () at libstd/rt.rs:59
#27 std::panicking::try::do_call () at libstd/panicking.rs:310
#28 0x0000000100a123c4 in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:102
#29 0x00000001009f13c0 in std::panicking::try () at libstd/panicking.rs:289
#30 std::panic::catch_unwind () at libstd/panic.rs:392
#31 std::rt::lang_start_internal () at libstd/rt.rs:58
#32 0x00000001000de600 in std::rt::lang_start ()
#33 0x00000001000eae88 in main ()

[sanxiyn]

Rust powerpc64 in fact requires AltiVec, see #59040.

[TheBlueMatt]

As noted this BT was on POWER9, ie including Altivec support.

…

On Mar 29, 2019, at 08:12, Seo Sanghyeon ***@***.***> wrote: Rust powerpc64 in fact requires AltiVec, see #59040. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[sanxiyn]

@TheBlueMatt, can you open a new issue? As your issue is clearly different from @aperezbios's.

[cuviper]

@TheBlueMatt's issue looks like #57345, which should be fixed by #58986.

[sanxiyn]

@TheBlueMatt, please confirm whether the issue is fixed in the latest nightly. Thanks!

[Enselic]

Triage: Can this issue still be reproduced? Wanted to ask since 6 years have passed and circumstances might have changed.

[TheBlueMatt]

I no longer regularly compile on ppc64el so don't readily have a test machine for this, sorry.