Rust (and librsvg, IceCat, etc.) fails to build on i686-linux

OpenSubmitted by Mark H Weaver.
Details
4 participants
  • Danny Milosavljevic
  • Ludovic Courtès
  • Mark H Weaver
  • Ricardo Wurmus
Owner
unassigned
Severity
important
M
M
Mark H Weaver wrote on 1 May 2019 05:43
librsvg broken on i686-linux
(address . bug-guix@gnu.org)
871s1ion48.fsf@netris.org
Hydra failed to build librsvg on i686-linux, because it depends on Rustwhich is still broken on i686-linux in Guix.
https://hydra.gnu.org/build/3477308
Mark
L
L
Ludovic Courtès wrote on 1 May 2019 09:25
control message for bug #35519
(address . control@debbugs.gnu.org)
87sgtyhc0d.fsf@gnu.org
severity 35519 important
D
D
Danny Milosavljevic wrote on 11 May 2019 02:00
Re: bug#35519: librsvg broken on i686-linux
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 35519@debbugs.gnu.org)
20190511020026.4d207749@scratchpost.org
Hi,
On Fri, 10 May 2019 14:53:40 +0200Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (10 lines)> > Hydra failed to build librsvg on i686-linux, because it depends on Rust> > which is still broken on i686-linux in Guix. > > Danny opened a bug report with the mrustc upstream:> > https://github.com/thepowersgang/mrustc/issues/108> > The last message there tells us to try again with current HEAD on> master.
I tried it now--it *does* work on i686 if I follow the README of mrustc andbuild both it and rust 1.19 using the Makefile of mrustc. (I haven't testedarmhf and x86_64 on mrustc master yet)
But when I use our separate package definitions it fails when building libcore(which is the first library for the target compiler).Invoke seems to swallow the output, so I have no idea where or why it failed(grr).
It's easily possible that some rust 1.19 build flags have to be adapted forthe newer mrustc, but I don't know which yet.(Obviously, mrustc's makefile and/or Cargo.tomls already did the adaptionif any)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzWEJoACgkQ5xo1VCwwuqUMGwf/X1wIRYI11bSQv8p6eK4mEQx6n0HBIel3Q+4TyVpPXfUvmXvKV16PTTJzCK0GOaSlCe+E9V6eEK4UfwCfBIBF3ROr+NY7MW2RYAftvsyrwN3G/6XRNhejTRFugEL6er6YQdA7JWAgo5NUWmFh7fOi6QBf0WG+66BlM10r9yiW4PN3unNkumD4ecj5/5DQKOWLh+Dumwtv5GCM0xU7zgy7lbl2BchoW16GLDV3CGZg/47C2iYOgdg9J/jI1g5OP7kiOsobE7UkC1Wuei/VmmuH7HSaYM0qMM35VTZ7JY6mOQqEHgX9bQiypiROh/2OuuhZdWFtEa99kBUQUJRWwEG4xw===8vuF-----END PGP SIGNATURE-----

M
M
Mark H Weaver wrote on 11 May 2019 10:03
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
878svd1kp3.fsf@netris.org
Hi Danny,
Danny Milosavljevic <dannym@scratchpost.org> writes:
Toggle quote (5 lines)> But when I use our separate package definitions it fails when building libcore> (which is the first library for the target compiler).> Invoke seems to swallow the output, so I have no idea where or why it failed> (grr).
Hmm. What makes you think that 'invoke' swallowed the output? Youmight be right, but 'invoke' is used quite widely by now in Guix,including to invoke 'make' in gnu-build-system, and I haven't seenreports of it swallowing output.
I looked at the code. 'invoke' calls 'system*' which calls'scm_open_process' (in libguile/posix.c) with an empty mode string.
In this case, the child STDOUT becomes (current-output-port) from theparent if (current-output-port) is a "file port", i.e. a Guile portbacked by a POSIX file descriptor, e.g. a file, socket or pipe. If it'sa Guile port that's not backed by a file descriptor, e.g. a custom port,soft port, string port, bytevector port, etc, then indeed the childoutput will go to /dev/null instead.
(Note that the port returned by 'open-pipe*' when used in OPEN_BOTH modeis also a soft port and not considered a file port, even though it isinternally backed by two file ports.)
Ditto for STDERR, except that it uses (current-error-port).
So, if 'invoke' seems to be swallowing output, it's probably because itwas called within the dynamic extent of 'with-output-to-port','with-error-to-port', 'with-output-to-string', or similar.
Regards, Mark
R
R
Ricardo Wurmus wrote on 10 May 2019 14:53
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 35519@debbugs.gnu.org)
87h8a2sc6j.fsf@elephly.net
Hi,
Toggle quote (3 lines)> Hydra failed to build librsvg on i686-linux, because it depends on Rust> which is still broken on i686-linux in Guix.
Danny opened a bug report with the mrustc upstream:
https://github.com/thepowersgang/mrustc/issues/108
The last message there tells us to try again with current HEAD onmaster. If this fails I think it’s acceptable to use a binary for thevery first Rust on i686; we would skip the use of mrustc on i686 then.Not great.
--Ricardo
D
D
Danny Milosavljevic wrote on 11 May 2019 16:08
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 35519@debbugs.gnu.org)
20190511160859.7b486515@scratchpost.org
Extra info: guix mrustc seems to be compiled with gcc 8 but guix rust-1.19 with gcc 5.5. How did that happen? Doesn't sound like a good idea since one loads compiler plugins compiled using the other into the same process.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzW13sACgkQ5xo1VCwwuqVkUwf+JO5O5vzY/cqyJBxFyH1v+PocfR6oQNN+6xX7B7sHrrClHbe+DGvv3SbYyiLT3q1+fk6AZ0IBKEfU/zd2rYrsxCW9Q7+DigRqPAWju6QVAWsmQ4Y7RbcPlfkpCKAJbr/pCsr+RX3quNTnmx0UjQIjpa2y7usbaXkTEtFGLxsRuNbA44PVU8wxXYZ8C2qm92/nf6wqacgj0r3FenfXOE/Hr8j1kjpB0RhONPpiONlz/26aEU/KR8OprymsIJcqRqpMJhkftDDGdGBso2scy3UKXYG69Js2lp9J1IsAzqJDnFCwCuqVkZAck3qF/bnzpxxoAxls/NFk0Ao89FaJRXxrNw===BF7N-----END PGP SIGNATURE-----

D
D
Danny Milosavljevic wrote on 11 May 2019 16:16
(name . Mark H Weaver)(address . mhw@netris.org)
20190511161632.5c8e4d60@scratchpost.org
Hi Mark,
On Sat, 11 May 2019 04:03:41 -0400Mark H Weaver <mhw@netris.org> wrote:
Toggle quote (5 lines)> Hmm. What makes you think that 'invoke' swallowed the output? You> might be right, but 'invoke' is used quite widely by now in Guix,> including to invoke 'make' in gnu-build-system, and I haven't seen> reports of it swallowing output.
I found out what was up with invoke. The child process didn't outputanything on stdout or stderr, but it died with SIGFPE and I eitherwas unable to interpret invoke's exception properly, or it didn't say(probably the former).
It seems that mrustc uses a different gcc version than rust 1.19 whichseems to be a bad idea to me, but not sure whether it's the cause ofthe SIGFPE.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzW2UAACgkQ5xo1VCwwuqX6xgf/a0DjFDARBmexxw3PaMP74aOt2WuKoiXxFBX88Cz1vk87H6fz01zM0yah/9053OvAeXLXyVoJ/DcWypMWMrlA33nJ1IbLFb4GZd1naf7pMGsgh/aJuDVojYZP6jJCV8xMgZ4+Y8EBsluzt2b3TE826SSfQ/L0KqOHynCiKU1apERH8prqyLtEtHd+pKOLJdgXMUp9f7u7dTLrdpXX2d+8wjtw5pdOqYt8rqsMcAeBj3XB/x8oWA/qyjZN3v2HB91t6O1aD6PDGr3rYDS6sLHVgNIebT54ERvJtfQr6XAythnkBYgzdSk5Iyr23BgT6YgUeZn37BLkQJGCTMD8BxN5aA===9wlr-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 18 May 2019 14:05
control message for bug #35519
(address . control@debbugs.gnu.org)
87v9y8ufwy.fsf@gnu.org
retitle 35519 Rust (and librsvg, IceCat, etc.) fails to build on i686-linux
L
L
Ludovic Courtès wrote on 16 Sep 2019 14:24
Re: bug#35519: librsvg broken on i686-linux
(name . Ricardo Wurmus)(address . rekado@elephly.net)
87pnk0bf8v.fsf@gnu.org
Hello Danny and all,
Ricardo Wurmus <rekado@elephly.net> skribis:
Toggle quote (12 lines)>> Hydra failed to build librsvg on i686-linux, because it depends on Rust>> which is still broken on i686-linux in Guix.>> Danny opened a bug report with the mrustc upstream:>> https://github.com/thepowersgang/mrustc/issues/108>> The last message there tells us to try again with current HEAD on> master. If this fails I think it’s acceptable to use a binary for the> very first Rust on i686; we would skip the use of mrustc on i686 then.> Not great.
I don’t know if it relates but on current ‘core-updates’ Rust 1.19 failsto build on i686:
Toggle snippet (13 lines)BUILDING curl_sys from curl-sys v0.3.11 with features []> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/bin/mrustc src/vendor/curl-sys/lib.rs --crate-name curl_sys --crate-type rlib --crate-tag 0_3_11 -g --cfg debug_assertions -O -o output/cargo-build/libcurl_sys-0_3_11.hir -L output/cargo-build -L /gnu/store/44sdci2mizpvd70zyvbfs9ai0maw255z-curl-7.65.3/lib -l curl --extern libz_sys=output/cargo-build/liblibz_sys-1_0_13.hir --extern libc=output/cargo-build/liblibc-0_2_22.hir --extern openssl_sys=output/cargo-build/libopenssl_sys-0_9_12.hir -L output -L /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrustBUILDING curl from curl v0.4.6 with features []> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/bin/mrustc src/vendor/curl/src/lib.rs --crate-name curl --crate-type rlib --crate-tag 0_4_6 -g --cfg debug_assertions -O -o output/cargo-build/libcurl-0_4_6.hir -L output/cargo-build --extern libc=output/cargo-build/liblibc-0_2_22.hir --extern curl_sys=output/cargo-build/libcurl_sys-0_3_11.hir --extern openssl_sys=output/cargo-build/libopenssl_sys-0_9_12.hir --extern openssl_probe=output/cargo-build/libopenssl_probe-0_1_1.hir -L output -L /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrustBUILDING crates_io from crates-io v0.9.0 with features []> /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/bin/mrustc src/tools/cargo/src/crates-io/lib.rs --crate-name crates_io --crate-type rlib --crate-tag 0_9_0 -g --cfg debug_assertions -O -o output/cargo-build/libcrates_io-0_9_0.hir -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.hir --extern error_chain=output/cargo-build/liberror_chain-0_10_0.hir --extern serde=output/cargo-build/libserde-1_0_6.hir --extern serde_derive=output/cargo-build/libserde_derive-1_0_6.hir --extern serde_json=output/cargo-build/libserde_json-1_0_2.hir --extern url=output/cargo-build/liburl-1_4_0.hir -L output -L /gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrustmunmap_chunk(): invalid pointersrc/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: Unexpected EOF while reading from child processBUILD FAILEDcommand "/gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/tools/bin/minicargo" "src/tools/cargo" "--vendor-dir" "src/vendor" "--output-dir" "output/cargo-build" "-L" "output/" "-L" "/gnu/store/2fh0bz69j6gxpgj5nqiqplwmck1dvi47-mrustc-0.8.0/lib/mrust" "-j" "1" failed with status 1builder for `/gnu/store/01mh2n7mif0k49ivj6y3fdq1ssj3d2lq-rust-1.19.0.drv' failed with exit code 1
(Fromhttps://ci.guix.gnu.org/log/cnxzabs1mi42rfvz8gp34lqap0dwi9l6-rust-1.19.0-cargo.)
Does that ring a bell? Any ideas of a fix or workaround we could apply?
It’d be great if we could merge ‘core-updates’ soon. This isunfortunately not a regression compared to ‘master’, so I don’t thinkthis is a blocker.
Thoughts?
Ludo’.
D
D
Danny Milosavljevic wrote on 16 Sep 2019 18:11
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190916181141.40fdebe6@scratchpost.org
Hi Ludo,
On Mon, 16 Sep 2019 14:24:48 +0200Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (2 lines)> Does that ring a bell?
Yes, I've brought that up upstream and upstream is more than willing to workon this and debug this problem if there is a system to debug it on.
However, as far as I understand we decided not to give thepowersgang (authorsof mrustc) a login to a Guix machine--therefore, the situation will not improve.
The problem is NOT reproducible in Debian with the same gcc version.
Maybe I'll get my home internet set up next month and put a Guix machine on it,but right now I only have mobile internet (with very slow upload and behind NAT).As it is now, I cannot reasonably give someone a Guix machine already setupto debug this problem.
The problem is 100% reproducible and I estimate would be easy to fix for theauthors--and maybe would fix the similar armhf problems as well.
So if someone could put a Guix machine on the internet and give thepowersgangaccess, that would be great. I can't right now.
If that happens, I can instruct thepowersgang how to enter an environmentwhere this problem can be reproduced and fixed.
Even at the last FOSDEM, Chris Marusich and I saw this problem and fixedpart of it--by now we got upstream attention. (After all this inertia maybewe lost upstream attention again--we'll see)
Toggle quote (2 lines)> Any ideas of a fix or workaround we could apply?
No, but thepowersgang might find it very quickly. They guess it might besome C undefined behavior being used by the mrustc->C translator, or a problemwith the struct layout (although I've checked the latter and it should befine).
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl1/tD0ACgkQ5xo1VCwwuqWJ1Af/fMLcbj/bUBkHbVNKpYbrU+46A8Yrnth9IMdnbByGw3FcUCAZt7khyHvJU1wGLd4eG9iJxHxjMehWrckUia9d7OMg+WSNhdeHWL9cQ4vg/5TTr4yf63q/i/SCSD5f4cdWy+N7Eo4tkn3KcVkdQVmnrYfj7PIoiPaZ6aTXw1KlpCgIyEo9Pvc200g0OTDly2IZkvM3YeJkBQ/QenOwu6TJ39PbGmvtsytfogloN16/ybxT7WHBrmM+MDiJfXzPoDub3DuxFqstMslPvUfjdVrgNiZlClpUIo7YJiKNJxLTtVDafLvpq66aPi2xvPNDvh9P/31kZh1krORE4VGeii5rLw===A47n-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 16 Sep 2019 22:48
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)
877e682cid.fsf@gnu.org
Hi Danny,
Danny Milosavljevic <dannym@scratchpost.org> skribis:
Toggle quote (6 lines)> Yes, I've brought that up upstream and upstream is more than willing to work> on this and debug this problem if there is a system to debug it on.>> However, as far as I understand we decided not to give thepowersgang (authors> of mrustc) a login to a Guix machine--therefore, the situation will not improve.
What about giving them “guix pack mrustc”, or a guix-install.sh + pullcommand sequence, or a VM image?
The instructions would be:
1. Download and run https://guix.gnu.org/install.sh. It will perform the steps described at https://guix.gnu.org/manual/en/html_node/Binary-Installation.html.
2. Write this to a file:
(list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "0b2ea78173f05c417a9002e52e2b36b139074124")))
3. Run ‘guix pull -C that-file.scm -p ~/core-updates’.
4. Run ‘~/core-updates/bin/guix build rust -s i686-linux -K’. Investigate as per https://guix.gnu.org/manual/en/html_node/Debugging-Build-Failures.html.
Perhaps you could propose them to do that, and if that’s too much toask, we can meet halfway somehow.
Of course we can also provide guidance on #guix on IRC.
WDYT?
Toggle quote (5 lines)> No, but thepowersgang might find it very quickly. They guess it might be> some C undefined behavior being used by the mrustc->C translator, or a problem> with the struct layout (although I've checked the latter and it should be> fine).
Would Valgrind or ASan be able to flag the potential issue?
Thanks,Ludo’.
D
D
Danny Milosavljevic wrote on 18 Mar 21:45 +0100
guix master 4de63cf3fc0a831d75cb507456821104f24800c2: rust 1.19.0 build failure on i686-linux
(address . 35519@debbugs.gnu.org)
20200318214538.160d62bd@scratchpost.org
Hi,
so after our mrustc upgrade to 0.9, we get the following when building rust 1.19.0on guix master 4de63cf3fc0a831d75cb507456821104f24800c2 and i686-linux:
[...](75/77) BUILDING git2_curl from git2-curl v0.7.0
Toggle quote (1 lines)> /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/bin/mrustc src/vendor/git2-curl/src/lib.rs -o output/cargo-build/libgit2_curl-0_7_0.rlib --crate-name git2_curl --crate-type rlib -C emit-depfile=output/cargo-build/libgit2_curl-0_7_0.rlib.d --crate-tag 0_7_0 -g --cfg debug_assertions -O -L output -L /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/lib/mrust -L output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.rlib --extern url=output/cargo-build/liburl-1_4_0.rlib --extern log=output/cargo-build/liblog-0_3_7.rlib --extern git2=output/cargo-build/libgit2-0_6_6.rlib
(76/77) BUILDING cargo v0.20.0
Toggle quote (1 lines)> /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/bin/mrustc src/tools/cargo/src/cargo/lib.rs -o output/cargo-build/libcargo-0_20_0.rlib --crate-name cargo --crate-type rlib -C emit-depfile=output/cargo-build/libcargo-0_20_0.rlib.d --crate-tag 0_20_0 -g --cfg debug_assertions -O -L output -L /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/lib/mrust -L output/cargo-build --extern crates_io=output/cargo-build/libcrates_io-0_9_0.rlib --extern crossbeam=output/cargo-build/libcrossbeam-0_2_10.rlib --extern curl=output/cargo-build/libcurl-0_4_6.rlib --extern docopt=output/cargo-build/libdocopt-0_7_0.rlib --extern env_logger=output/cargo-build/libenv_logger-0_4_2.rlib --extern error_chain=output/cargo-build/liberror_chain-0_10_0.rlib --extern filetime=output/cargo-build/libfiletime-0_1_10.rlib --extern flate2=output/cargo-build/libflate2-0_2_19.rlib --extern fs2=output/cargo-build/libfs2-0_4_1.rlib --extern git2=output/cargo-build/libgit2-0_6_6.rlib --extern git2_curl=output/cargo-build/libgit2_curl-0_7_0.rlib --extern glob=output/cargo-build/libglob-0_2_11.rlib --extern jobserver=output/cargo-build/libjobserver-0_1_6.rlib --extern libc=output/cargo-build/liblibc-0_2_22.rlib --extern libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.rlib --extern log=output/cargo-build/liblog-0_3_7.rlib --extern num_cpus=output/cargo-build/libnum_cpus-1_4_0.rlib --extern rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.rlib --extern scoped_tls=output/cargo-build/libscoped_tls-0_1_0.rlib --extern semver=output/cargo-build/libsemver-0_7_0.rlib --extern serde=output/cargo-build/libserde-1_0_6.rlib --extern serde_derive=output/cargo-build/libserde_derive-1_0_6-plugin --extern serde_ignored=output/cargo-build/libserde_ignored-0_0_3.rlib --extern serde_json=output/cargo-build/libserde_json-1_0_2.rlib --extern shell_escape=output/cargo-build/libshell_escape-0_1_3.rlib --extern tar=output/cargo-build/libtar-0_4_13.rlib --extern tempdir=output/cargo-build/libtempdir-0_3_5.rlib --extern term=output/cargo-build/libterm-0_4_5.rlib --extern toml=output/cargo-build/libtoml-0_4_1.rlib --extern url=output/cargo-build/liburl-1_4_0.rlib --extern openssl=output/cargo-build/libopenssl-0_9_12.rlib
BUILDING cargo v0.20.0
Toggle quote (1 lines)> /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/bin/mrustc src/tools/cargo/src/bin/cargo.rs -o output/cargo-build/cargo --crate-name cargo --crate-type bin -C emit-depfile=output/cargo-build/cargo.d --crate-tag 0_20_0 -g --cfg debug_assertions -O -L output -L /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/lib/mrust -L output/cargo-build --extern cargo=output/cargo-build/libcargo-0_20_0.rlib --extern crates_io=output/cargo-build/libcrates_io-0_9_0.rlib --extern crossbeam=output/cargo-build/libcrossbeam-0_2_10.rlib --extern curl=output/cargo-build/libcurl-0_4_6.rlib --extern docopt=output/cargo-build/libdocopt-0_7_0.rlib --extern env_logger=output/cargo-build/libenv_logger-0_4_2.rlib --extern error_chain=output/cargo-build/liberror_chain-0_10_0.rlib --extern filetime=output/cargo-build/libfiletime-0_1_10.rlib --extern flate2=output/cargo-build/libflate2-0_2_19.rlib --extern fs2=output/cargo-build/libfs2-0_4_1.rlib --extern git2=output/cargo-build/libgit2-0_6_6.rlib --extern git2_curl=output/cargo-build/libgit2_curl-0_7_0.rlib --extern glob=output/cargo-build/libglob-0_2_11.rlib --extern jobserver=output/cargo-build/libjobserver-0_1_6.rlib --extern libc=output/cargo-build/liblibc-0_2_22.rlib --extern libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.rlib --extern log=output/cargo-build/liblog-0_3_7.rlib --extern num_cpus=output/cargo-build/libnum_cpus-1_4_0.rlib --extern rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.rlib --extern scoped_tls=output/cargo-build/libscoped_tls-0_1_0.rlib --extern semver=output/cargo-build/libsemver-0_7_0.rlib --extern serde=output/cargo-build/libserde-1_0_6.rlib --extern serde_derive=output/cargo-build/libserde_derive-1_0_6-plugin --extern serde_ignored=output/cargo-build/libserde_ignored-0_0_3.rlib --extern serde_json=output/cargo-build/libserde_json-1_0_2.rlib --extern shell_escape=output/cargo-build/libshell_escape-0_1_3.rlib --extern tar=output/cargo-build/libtar-0_4_13.rlib --extern tempdir=output/cargo-build/libtempdir-0_3_5.rlib --extern term=output/cargo-build/libterm-0_4_5.rlib --extern toml=output/cargo-build/libtoml-0_4_1.rlib --extern url=output/cargo-build/liburl-1_4_0.rlib --extern openssl=output/cargo-build/libopenssl-0_9_12.rlib
"libcore"command "output/rustc-build/rustc" "-C" "linker=/gnu/store/y7dd2178bbpy7pl09fdn1r9412rc2mm3-gcc-7.4.0/bin/gcc" "-Z" "force-unstable-if-unmarked" "-L" "output/target-libs" "src/libcore/lib.rs" "-o" "output/target-libs/libcore.rlib" failed with signal 8
That's extremely good, but signal 8 is SIGFPE, as before.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl5yiHIACgkQ5xo1VCwwuqW96Af9GQd5EA9/l4SpVDEGBJu98G8jaW/Y32oVFRybdUbTZG1+c1yWzhk+EHs2eqJ7emCo889d8OPuyXxsY9RvDMf8Onp299H/VsKSWF0IA+8sbsnLuy9JuD+oCx4fPzjnus3HNGPeyYsnocPUtHSVNrYvHabX8+eKsbOK5pf1P7qFxKriF21nQyM68r0XJURKBvDApGkGwCtI6HKq7Rkcl2rtnXsWBb6OS4mTj2GPitmULtlndmaU2yu4JMwO+0nQBSE6m8Pf+KbLdL/7gMAJwUU8qMP4hN1Qkiq9RiH31On59XOo/CZLgkvqdAgIT5roRz2Bkww7xKKubMLwbmI6WHOm1g===7Pn4-----END PGP SIGNATURE-----

?