Change:
source shared.sh <ins> BINUTILS=2.32 TARGET=powerpc64-unknown-linux-gnu PREFIX=/x-tools/$TARGET SYSROOT=$PREFIX/$TARGET/sysroot </ins> mkdir build cd build cp ../powerpc64-linux-gnu.config .config hide_output ct-ng build cd .. rm -rf build <ins> chmod -R u+w $PREFIX # Next, download and build newer binutils. mkdir binutils-$TARGET pushd binutils-$TARGET curl https://ftp.gnu.org/gnu/binutils/binutils-$BINUTILS.tar.bz2 | tar xjf - mkdir binutils-build cd binutils-build hide_output ../binutils-$BINUTILS/configure --target=$TARGET  --prefix=$PREFIX --with-sysroot=$SYSROOT hide_output make -j10 hide_output make install popd rm -rf binutils-$TARGET </ins>

Discussion:
hello, cargo nightly-2018-09-30 shipped through rustup crashes on startup on ppc64le. cargo binary compiled on my machine from sources on master or branch rust-1.32.0 runs fine crash log My machine is a RaptorCS Talos II, it has an IBM POWER9 processor, my system is Fedora 29 with latest updates. I would guess this is a build environment issue on your end; please indicate how I can help, thanks a lot for your time!
Thanks for the report. Seems very similar that occurs on big endian...
I saw that other issue before; the backtrace is largely different, and recompiling just works so. I am confused as to how it could not build correctly, I built mine with stable 1.30.1 and it's OK. I had to modify the source a little to allow use of experimental clippy features.
And so it does for the big endian. Why I think these are similar issues is because just like in the other report the pc is somewhere around or some similar very-round number. Basically it feels to me that we simply embed a bad openssl for either PPC. It could be caused by an older toolchain, older openssl source or some other reason. I do agree that it is likely an infrastructure issue.
The SIGIILL is happening because the program has branched somewhere that's not code. In fact it branches to 0 (relocated) which is the start of the ELF. It seems to be coming from here: Which is also what we see in the obdump: So for some reason we have a branch to address 0, but there's nothing at address 0 and in fact there isn't even code there. Which looks like some sort of toolchain screwup. If I build openssl and look at the objdump of I think this matches up with this code (code-gen is not identical): So it's the call to that's resulted in the bad branch. And interestingly is a weak symbol: And: That leads us to this issue: Which suggests the call requires GLIBC 2.25 or newer to work. I don't actually know where or how the rust ppc64le binaries are built.

But it looks like they are built against glibc 2.17: Presumably building on a system with GLIBC 2.25 or newer would fix the issue.
I have GLIBC 2.28 over here, so that's probably it, thanks for the detailed investigation
cc ~
cc Updating the docker images should be fairly easy, I think.
cc I'm not sure if it's as easy as just updating our images since I suspect that'll break other use cases in practice (we're on them for a reason after all).
Upgrading only the binutils usually doesn't break compatibility with older systems but without running it on older PPC distro you can't really know.
Where/how are the builds done currently?
If it's just a binutils upgrade that's fine to land at any time, and they're located in files which configures all our distribution builds.
I've confirmed that the official builds are fixed as of .
I confirm too, however, the stable builds are not, could you run a rebuild? Thanks.
The official builds are only updated as part of the release process. I'll nominate my PR for beta and stable, but I'm not aware of any plans for a 1.33.z point release.
Well the builds don't work at all, it's not a new release, rather a build system update? Don't change the version? I don't know if that's OK with rustup.
Our build system fetches its configuration from the source code it's building, so to get patch in we'd have to make an actual point release.
Okay then, when (approximate) should I expect the next stable release?
You can see projected release dates on this page:
Thank you PowerPC will not have working stable releases from rustup until the 11th of April 2019, unless you make a point release. I'd appreciate if you did make one, if the same thing happened on x86, you'd make one. Thanks for all the great work.
Certainly, but x86 bootstraps everything else -- it cannot be left broken. There is also a notion of , where i686 and x86_64 are tier 1, and other arches are tier 2, "not guaranteed to produce a working build." (but also "patches are always welcome!" as I have provided in this case.)

Since you're on Fedora, is there a reason you can't just use its rust packages? (I'm also the package maintainer there.)
There's no platform with tier1 support that can run without proprietary firmware, or else, old computers. Fedora packages are not nightly and installing both rustup and Fedora packages is not supported. I often have to switch between stable and nightly for diverse projects with different requirements.
it's not officially supported but you can point to your system toolchain as explained here: This way you can make toolchain the default on and use .
Oh cool! Thank you, that will come in handy. I had previously been looking for such a thing and did not find it.
Now there's another problem, it's that IntelliJ IDEA with Rust support wont install additional components automatically because the "system" toolchain does not support that. But it's OK, I can code with nightly and compile with stable or nightly as needed.
Unfortunately it looks like 1.34 also exhibits this issue.
Correct, the infrastructure team declined the backport: The current beta 1.35 and forward should be fine.
It should have been fixed for 1.34. It's not like a binutils update requires any kind of stabilization, especially in front of something that does not work.
Explained the reason why the backport to 1.34 was rejected in .