Created attachment 516530 [details] build.log from failing machine Today, dev-lang/rust-1.23.0 tried to land on two of my 32 bit ~x86 systems. Both of these are very similar software-wise, but hardware-wise there are some differences. On of the systems is Intel-based... boerne (GCC7) ~ # uname -a Linux boerne 4.14.15-gentoo #2 SMP Wed Jan 24 12:16:21 CET 2018 i686 Pentium(R) Dual-Core CPU T4300 @ 2.10GHz GenuineIntel GNU/Linux ... and on that system, the rust-1.23.0 build process seems to work fine. In fact, it is still in progress at this time, but it looks very sane and normal. The other machine is AMD-based... teela (GCC7) ~ # uname -a Linux teela 4.14.15-gentoo #2 SMP Wed Jan 24 14:52:44 CET 2018 i686 AMD E1-2100 APU with Radeon(TM) HD Graphics AuthenticAMD GNU/Linux ...and on this machine, the rust-1.23.0 build process fails before it's even really started: >>> Compiling source in /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src ... running: /var/tmp/portage/dev-lang/rust-1.23.0/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen Compiling libc v0.2.33 Compiling num-traits v0.1.40 Running `/var/tmp/portage/dev-lang/rust-1.23.0/work/rust-stage0/bin/rustc --crate-name libc src/vendor/libc/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=af60d7cf618a310d -C extra-filename=-af60d7cf618a310d --out-dir /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps --cap-lints warn` Running `/var/tmp/portage/dev-lang/rust-1.23.0/work/rust-stage0/bin/rustc --crate-name num_traits src/vendor/num-traits/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on -C metadata=879e9e44dbacc37f -C extra-filename=-879e9e44dbacc37f --out-dir /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps --cap-lints warn` error: Could not compile `libc`. Caused by: process didn't exit successfully: `/var/tmp/portage/dev-lang/rust-1.23.0/work/rust-stage0/bin/rustc --crate-name libc src/vendor/libc/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg feature="default" --cfg feature="use_std" -C metadata=af60d7cf618a310d -C extra-filename=-af60d7cf618a310d --out-dir /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps --cap-lints warn` (signal: 11, SIGSEGV: invalid memory reference) warning: build failed, waiting for other jobs to finish... error: Could not compile `num-traits`. Interestingly, when I now change into the directory /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src and execute the command that was reported as failing manually, i.e. /var/tmp/portage/dev-lang/rust-1.23.0/work/rust-stage0/bin/rustc --crate-name libc src/vendor/libc/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg feature="default" --cfg feature="use_std" -C metadata=af60d7cf618a310d -C extra-filename=-af60d7cf618a310d --out-dir /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps --cap-lints warn it seems to complete without error and appropriate output is also generated in out-dir (/var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps). In fact, when I now re-start the build process (by means of the "ebuild" command, for example), the process seems to even get ahead one more step, only complaining about being unable to compile the next "component" (or whatever it's called in rust-lingo) and presenting me the related failing command. However, once again, it seems that this command will run just fine when I execute it by hand, after which I could restart the build process once more ... and ... well, if I were persistent enough, one might guess that I could probably get the whole thing built that way. ;-) Anyway, this clearly looks strange and I'm kind of at loss understanding why it only happens on the AMD machine. I tried several things just to see if they make a difference, actually ... like modifying the ebuild to use a different stage 0 (rust-1.22.1-i686-unknown-linux-gnu.tar.gz or rust-1.20.0-i686-unknown-linux-gnu.tar.gz), but that didn't make any difference. Complete build log and emerge --info from the failing machine is attached!
Created attachment 516532 [details] emerge --info rust from failing machine
Addendum(tm): When the things fail, the following turns up in syslog: Jan 25 11:44:04 teela kernel: traps: rustc[1966] general protection ip:b7b09e8f sp:b2fface8 error:0 in libc-2.26.so[b7a12000+1d8000] Jan 25 11:44:04 teela kernel: traps: rustc[1968] general protection ip:b7ae3e8f sp:b2fface8 error:0 in libc-2.26.so[b79ec000+1d8000] Jan 25 11:44:05 teela systemd[1]: Started Process Core Dump (PID 1967/UID 0). Jan 25 11:44:05 teela systemd[1]: Started Process Core Dump (PID 1969/UID 0). Jan 25 11:44:05 teela systemd-coredump[1970]: Process 1963 (rustc) of user 250 dumped core. Jan 25 11:44:06 teela systemd-coredump[1971]: Process 1965 (rustc) of user 250 dumped core. So some problem in the libc on the machine? Hmmm ... didn't notice any other issues recently besides this rust-building related one. Probably it's the combination of the precompiled rust-stage0 and my libc? Anyway, I'm trying something now: I modified the ebuild so that it doesn't use the rustc and cargo included in the stage0, but instead uses my system's /usr/bin/rustc and /usr/bin/cargo. These have been compiled locally, and my system's rust is at 1.19.0 currently. Will building rust-1.23.0 that way succeed? Good question, currently things look good, but the process is ongoing. That raises a general question, however: Is it really always required and / or the best idea to download a pre-compiled stage0 and use that to bootstrap a new rust-release to be compiled locally? If a system already sports a (sufficiently recent) rust installation, can't that one be used to bootstrap the new release in general? Don't hit me if this is nonsense - I'm not really a rust expert, I basically only have it on my systems because firefox requires it, but now that it's there, I'd certainly be all for it working as well as possible for anyone. :-)
Another update: Nope, building with the system instance of rustc and cargo leads to other errors down the way. However, whatever is wrong here doesn't seem like a general Gentoo bug. What I can say so far is that attempting to build any rustc release > 1.19.0 seems to fail on my gentoo system, even when attempted manually (i.e. by not using an ebuild, but the regular rust build procedure). The weird thing is that every command that fails during the automated build process (with signal: 11, SIGSEGV: invalid memory reference) works just fine when subsequently executed by hand. Just to have a comparison, I used debootstrap on my Gentoo system in order to set up a debian sid installation, which I then launched via systemd-nspawn in order to attempt to manually build rustc in there, and that does seem to work fine. So the problem might just be related to my particular system. I'll be investigating during the next few days and will report if I find anything of interest to the community as a whole. Concerning this bug report, I have a feeling that there's not much the Gentoo devs could or should do at this point. Therefore, I would have no objections if the issue gets closed. Still, if anyone should stumble over similar issues and find this report here, it'd probably be nice if they could leave a comment!
Alright, a final (hopefully) update. In general, there are two things that I can do to make things work. First, some background: On my AMD machine where the problems were present, I am using the following CFLAGS: CFLAGS="-O3 -march=native -mfpmath=sse -pipe -fomit-frame-pointer -fno-stack-protector" I tried rebuilding my glibc for a test, but still, when using a rustc snapshot provided by the rust folks, I get stuff like: process didn't exit successfully: `/var/tmp/portage/dev-lang/rust-1.23.0/work/rust-stage0/bin/rustc --crate-name libc src/vendor/libc/src/lib.rs --crate-type lib --emit=dep-info,link -C debug-assertions=off -C overflow-checks=on --cfg feature="default" --cfg feature="use_std" -C metadata=af60d7cf618a310d -C extra-filename=-af60d7cf618a310d --out-dir /var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps -L dependency=/var/tmp/portage/dev-lang/rust-1.23.0/work/rustc-1.23.0-src/build/bootstrap/debug/deps --cap-lints warn` (signal: 11, SIGSEGV: invalid memory reference) Now the two things that were able to fix it: 1) In an ad-hoc Debian, pulled into my Gentoo system with debootstrap and booted as a container via systemd-nspawn, I was successfully to build rustc using the procedure specified by the rust folks. If I copy the resulting build directory over to my Gentoo system and modify the rust-1.23.0 rebuild to use the rustc from the stage2 subdir of that build directory (instead of the official rust snapshot downloaded from the Internet), things work fine. In other words, the rustc I've build myself in the Debian container works fine on my Gentoo system. 2) I created a snapshot of my Gentoo system and also booted into that one via systemd-nspawn. In there, I rebuild my glibc with the following changed CFLAGS: CFLAGS="-march=i686 -pipe -fomit-frame-pointer" and now, all of a sudden, the rustc in the official snapshot tarballs provided by the rust project works without issues as well. So, as a bottom line, there is obviously an issue with the way I'm building my glibc and the way the official snapshot rustc is built. In theory, other users could certainly also stumble in such a situation. For my particular situation, I'll probably create myself custom rust-1.23.0 ebuilds which use my own snapshot from solution 1), because I don't feel like changing the way I'm building my glibc. After all, I've been building it like this for quite a while, and except for the issue with the pre-compiled rustc, have not had any issues. -> Setting the bug report to resolved, as there's probably nothing more to do at this point.
