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 Rust
which is still broken on i686-linux in Guix.
Mark
on 30 Apr 2019 20:43
on 1 May 2019 00:25
on 10 May 2019 17:00
on 10 May 2019 05:53
on 18 Dec 2020 07:19
on 19 Oct 2021 14:44
Rust (and librsvg, IceCat, etc.) fails to build on i686-linux
- Open
Details
- 6 participants
- Danny Milosavljevic
- Ludovic Courtès
- Mark H Weaver
- Mathieu Othacehe
- Ricardo Wurmus
- scottworley
- Owner
- unassigned
- Submitted by
- Mark H Weaver
- Severity
- important
control message for bug #35519
(address . control@debbugs.gnu.org)
87sgtyhc0d.fsf@gnu.org
severity 35519 important
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 +0200
Ricardo 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 and
build both it and rust 1.19 using the Makefile of mrustc. (I haven't tested
armhf 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 for
the newer mrustc, but I don't know which yet.
(Obviously, mrustc's makefile and/or Cargo.tomls already did the adaption
if any)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzWEJoACgkQ5xo1VCww
uqUMGwf/X1wIRYI11bSQv8p6eK4mEQx6n0HBIel3Q+4TyVpPXfUvmXvKV16PTTJz
CK0GOaSlCe+E9V6eEK4UfwCfBIBF3ROr+NY7MW2RYAftvsyrwN3G/6XRNhejTRFu
gEL6er6YQdA7JWAgo5NUWmFh7fOi6QBf0WG+66BlM10r9yiW4PN3unNkumD4ecj5
/5DQKOWLh+Dumwtv5GCM0xU7zgy7lbl2BchoW16GLDV3CGZg/47C2iYOgdg9J/jI
1g5OP7kiOsobE7UkC1Wuei/VmmuH7HSaYM0qMM35VTZ7JY6mOQqEHgX9bQiypiRO
h/2OuuhZdWFtEa99kBUQUJRWwEG4xw==
=8vuF
-----END PGP SIGNATURE-----
(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? 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 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 the
parent if (current-output-port) is a "file port", i.e. a Guile port
backed by a POSIX file descriptor, e.g. a file, socket or pipe. If it's
a 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 child
output will go to /dev/null instead.
(Note that the port returned by 'open-pipe*' when used in OPEN_BOTH mode
is also a soft port and not considered a file port, even though it is
internally 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 it
was called within the dynamic extent of 'with-output-to-port',
'with-error-to-port', 'with-output-to-string', or similar.
Regards,
Mark
(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:
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.
--
Ricardo
(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-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzW13sACgkQ5xo1VCww
uqVkUwf+JO5O5vzY/cqyJBxFyH1v+PocfR6oQNN+6xX7B7sHrrClHbe+DGvv3SbY
yiLT3q1+fk6AZ0IBKEfU/zd2rYrsxCW9Q7+DigRqPAWju6QVAWsmQ4Y7RbcPlfkp
CKAJbr/pCsr+RX3quNTnmx0UjQIjpa2y7usbaXkTEtFGLxsRuNbA44PVU8wxXYZ8
C2qm92/nf6wqacgj0r3FenfXOE/Hr8j1kjpB0RhONPpiONlz/26aEU/KR8Opryms
IJcqRqpMJhkftDDGdGBso2scy3UKXYG69Js2lp9J1IsAzqJDnFCwCuqVkZAck3qF
/bnzpxxoAxls/NFk0Ao89FaJRXxrNw==
=BF7N
-----END PGP SIGNATURE-----
(name . Mark H Weaver)(address . mhw@netris.org)
20190511161632.5c8e4d60@scratchpost.org
Hi Mark,
On Sat, 11 May 2019 04:03:41 -0400
Mark 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 output
anything on stdout or stderr, but it died with SIGFPE and I either
was 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 which
seems to be a bad idea to me, but not sure whether it's the cause of
the SIGFPE.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzW2UAACgkQ5xo1VCww
uqX6xgf/a0DjFDARBmexxw3PaMP74aOt2WuKoiXxFBX88Cz1vk87H6fz01zM0yah
/9053OvAeXLXyVoJ/DcWypMWMrlA33nJ1IbLFb4GZd1naf7pMGsgh/aJuDVojYZP
6jJCV8xMgZ4+Y8EBsluzt2b3TE826SSfQ/L0KqOHynCiKU1apERH8prqyLtEtHd+
pKOLJdgXMUp9f7u7dTLrdpXX2d+8wjtw5pdOqYt8rqsMcAeBj3XB/x8oWA/qyjZN
3v2HB91t6O1aD6PDGr3rYDS6sLHVgNIebT54ERvJtfQr6XAythnkBYgzdSk5Iyr2
3BgT6YgUeZn37BLkQJGCTMD8BxN5aA==
=9wlr
-----END PGP SIGNATURE-----
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
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 fails
to 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/mrust
BUILDING 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/mrust
BUILDING 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/mrust
munmap_chunk(): invalid pointer
src/tools/cargo/src/crates-io/lib.rs:65: BUG:src/expand/proc_macro.cpp:941: Unexpected EOF while reading from child process
BUILD FAILED
command "/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 1
builder for `/gnu/store/01mh2n7mif0k49ivj6y3fdq1ssj3d2lq-rust-1.19.0.drv' failed with exit code 1
(From
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 is
unfortunately not a regression compared to ‘master’, so I don’t think
this is a blocker.
Thoughts?
Ludo’.
(name . Ludovic Courtès)(address . ludo@gnu.org)
20190916181141.40fdebe6@scratchpost.org
Hi Ludo,
On Mon, 16 Sep 2019 14:24:48 +0200
Ludovic 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 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.
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 setup
to debug this problem.
The problem is 100% reproducible and I estimate would be easy to fix for the
authors--and maybe would fix the similar armhf problems as well.
So if someone could put a Guix machine on the internet and give thepowersgang
access, that would be great. I can't right now.
If that happens, I can instruct thepowersgang how to enter an environment
where this problem can be reproduced and fixed.
Even at the last FOSDEM, Chris Marusich and I saw this problem and fixed
part of it--by now we got upstream attention. (After all this inertia maybe
we 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 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).
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl1/tD0ACgkQ5xo1VCww
uqWJ1Af/fMLcbj/bUBkHbVNKpYbrU+46A8Yrnth9IMdnbByGw3FcUCAZt7khyHvJ
U1wGLd4eG9iJxHxjMehWrckUia9d7OMg+WSNhdeHWL9cQ4vg/5TTr4yf63q/i/SC
SD5f4cdWy+N7Eo4tkn3KcVkdQVmnrYfj7PIoiPaZ6aTXw1KlpCgIyEo9Pvc200g0
OTDly2IZkvM3YeJkBQ/QenOwu6TJ39PbGmvtsytfogloN16/ybxT7WHBrmM+MDiJ
fXzPoDub3DuxFqstMslPvUfjdVrgNiZlClpUIo7YJiKNJxLTtVDafLvpq66aPi2x
vPNDvh9P/31kZh1krORE4VGeii5rLw==
=A47n
-----END PGP SIGNATURE-----
(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 + pull
command 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
2. Write this to a file:
(list (channel
(name 'guix)
(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
Perhaps you could propose them to do that, and if that’s too much to
ask, 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’.
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.0
on 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-----
iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl5yiHIACgkQ5xo1VCww
uqW96Af9GQd5EA9/l4SpVDEGBJu98G8jaW/Y32oVFRybdUbTZG1+c1yWzhk+EHs2
eqJ7emCo889d8OPuyXxsY9RvDMf8Onp299H/VsKSWF0IA+8sbsnLuy9JuD+oCx4f
Pzjnus3HNGPeyYsnocPUtHSVNrYvHabX8+eKsbOK5pf1P7qFxKriF21nQyM68r0X
JURKBvDApGkGwCtI6HKq7Rkcl2rtnXsWBb6OS4mTj2GPitmULtlndmaU2yu4JMwO
+0nQBSE6m8Pf+KbLdL/7gMAJwUU8qMP4hN1Qkiq9RiH31On59XOo/CZLgkvqdAgI
T5roRz2Bkww7xKKubMLwbmI6WHOm1g==
=7Pn4
-----END PGP SIGNATURE-----
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 35519@debbugs.gnu.org)
877dpfkuq9.fsf@gnu.org
Hello,
The CI is spending a considerable amount of time trying to build Rust
packages for "i686-linux". As this is currently broken, what do you
think about applying the attached patch?
Thanks,
Mathieu
From 2ed5c6e3f8d77ed7b00995fcf786bf84033b76d9 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <othacehe@gnu.org>
Date: Fri, 18 Dec 2020 16:15:16 +0100
Subject: [PATCH] gnu: rust: Remove "i686-linux" from supported systems.
* gnu/packages/rust.scm (rust-1.19): Only support "x86_64-linux" architecture.
---
gnu/packages/rust.scm | 1 +
1 file changed, 1 insertion(+)
Toggle diff (14 lines)
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 35a96b5754..91b5d6b6ec 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -452,6 +452,7 @@ test = { path = \"../libtest\" }
(variable "LIBRARY_PATH")
(files '("lib" "lib64")))))
+ (supported-systems '("x86_64-linux"))
(synopsis "Compiler for the Rust programming language")
(description "Rust is a systems programming language that provides memory
safety and thread safety guarantees.")
--
2.29.2
(name . Mathieu Othacehe)(address . othacehe@gnu.org)
20201220142043.2049b1d9@scratchpost.org
Hi,
On Fri, 18 Dec 2020 16:19:10 +0100
Mathieu Othacehe <othacehe@gnu.org> wrote:
Toggle quote (4 lines)
> The CI is spending a considerable amount of time trying to build Rust
> packages for "i686-linux". As this is currently broken, what do you
> think about applying the attached patch?
Sure, for the time being.
But seriously, mrustc supports a lot of other architectures (including
defining custom architectures in config), and also can bootstrap Rust
1.29.0 directly. It's better to just update mrustc.
(Marius Bakke already tried to integrate the mrustc update to
core-updates--not sure what the roadblock was. Even if there was a
roadblock, mrustc upstream was committed to 7 days ago--maybe the roadblock
is gone now ?)
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl/fT/gACgkQ5xo1VCww
uqWbYgf+OfFi1lnPMHh7f6SE+QtNgZ3WF0Azm4nSFTPYMCQZ00T1fJa/NHdYoX5J
1s7N0EZiOw3fVG4k2rLoEVl2aHA+tWM3GO2FeiARMxWPS6Xp5j/tlBSx/TfcFB+I
n/VXaZdIMalW7teMHI6LGG6CQn6uWVW7aLkZeQScYSJiTDvs/bVUYC5EF105vrZv
PEuZLTcmXvvStA16+YEmfxycDYwDIh2ph65Qf4IQEKShEUzsZ8luteHQGncbX9UK
+t2diNm45ZeLlbUUO5sjsGW105DVNPO7p/3v1Ob1bpYMRgp5VdkcOKzwsELWocPw
X+86nqTpdhBKlZrWN27KRxgUOlqErQ==
=eUzh
-----END PGP SIGNATURE-----
Rust (and librsvg, IceCat, etc.) fails to build on i686-linux
(address . 35519@debbugs.gnu.org)
YW88L4qg2cTEZejk@chkno.net
?