Summary: | dev-lang/rust-1.48.0: could not compile `rustc_middle` | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Craig Andrews <candrews> |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | amanzharov, anton.gubarkov, candrews, dennis.lissov, flippynelle, ionen, matej, navi, randy, rust, sunk67188 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/rust-lang/rust/issues/76213 | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=904998 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.gz
gdb stack dump (2 ways) - use xzless to read |
Description
Craig Andrews
2020-11-24 15:00:44 UTC
Created attachment 674725 [details]
build.log.gz
can you try building without -Ctarget-cpu=native ? I've ran into the same thing as well earlier and, as upstream bug mentions, removing -Ctarget-cpu=native (which resolves to skylake in my case), did fix it. On another note, would be handy if emerge --info started showing RUSTFLAGS. yeah I wanted to extend emerge --info output like 2 years ago it was rejected due to rust being not that widespread. But I think it's time to re-visit, since we've got librsvg and spidermonkey deps on rust and it's installed on a lot of user systems. Created attachment 675832 [details] gdb stack dump (2 ways) - use xzless to read Been hitting this while emerging =gnome-base/librsvg-2.48.9 with rust 1.48.0 and that -Ctarget-cpu=skylake because it happens in librsvg's glib 0.9.3 In other words: 1. cd /tmp 2. git clone https://github.com/gtk-rs/glib.git 3. cd glib 4. cargo build --release Compiling glib v0.9.3 (/tmp/glib) error: could not compile `glib` Caused by: process didn't exit successfully: `rustc --crate-name glib src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C metadata=2352bc1dd9715572 -C extra-filename=-2352bc1dd9715572 --out-dir /tmp/glib/target/release/deps -L dependency=/tmp/glib/target/release/deps --extern bitflags=/tmp/glib/target/release/deps/libbitflags-3481844fb16a27e3.rmeta --extern futures_channel=/tmp/glib/target/release/deps/libfutures_channel-acf2f595b567337f.rmeta --extern futures_core=/tmp/glib/target/release/deps/libfutures_core-5724616e089f1a94.rmeta --extern futures_executor=/tmp/glib/target/release/deps/libfutures_executor-1b129915820c5715.rmeta --extern futures_task=/tmp/glib/target/release/deps/libfutures_task-78c8234e64a1f90a.rmeta --extern futures_util=/tmp/glib/target/release/deps/libfutures_util-43653a78ce31e82b.rmeta --extern glib_sys=/tmp/glib/target/release/deps/libglib_sys-f51e12252d7c06a1.rmeta --extern gobject_sys=/tmp/glib/target/release/deps/libgobject_sys-8334a4d73fff92c1.rmeta --extern lazy_static=/tmp/glib/target/release/deps/liblazy_static-53201e5af8cd3135.rmeta --extern libc=/tmp/glib/target/release/deps/liblibc-b4a06f67ef62b8d1.rmeta -C target-cpu=skylake -Z treat-err-as-bug=5 -Z macro-backtrace` (signal: 11, SIGSEGV: invalid memory reference) If I don't use "--release" then it's ok. If I don't use "-C target-cpu=skylake" then it's ok too. If I use "-C opt-level=0" or "-C opt-level=1" then it's ok. Fails with =2 or =3(default) RUSTFLAGS="-C target-cpu=skylake -Z treat-err-as-bug=5 -Z macro-backtrace" Is this rust or llvm at fault? does anyone know? $ llc --version LLVM (http://llvm.org/): LLVM version 11.0.0 Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: skylake Registered Targets: amdgcn - AMD GCN GPUs bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit r600 - AMD GPUs HD2XXX-HD6XXX x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 $ rustv rustc 1.48.0-nightly binary: rustc commit-hash: unknown commit-date: unknown host: x86_64-unknown-linux-gnu release: 1.48.0-nightly LLVM version: 11.0 cargo 1.48.0-nightly release: 1.48.0 Came from https://github.com/rust-lang/rust/issues/76213#issuecomment-733146725 forgot one step: 3_1') git checkout 0.9.3 because it's not an issue that happens in master (0.10.0) (In reply to flippynelle from comment #5) > > If I don't use "--release" then it's ok. > If I don't use "-C target-cpu=skylake" then it's ok too. > If I use "-C opt-level=0" or "-C opt-level=1" then it's ok. Fails with =2 or > =3(default) > release profile usually enables optimizations and/or lto, it can explain why you see it. if you don't pass --release, debug profile is used, which disables optimizations. Looks like they found it as an llvm bug: https://bugs.llvm.org/show_bug.cgi?id=48340 via https://github.com/rust-lang/rust/issues/79564#issuecomment-736102763 upstream merged a revert https://github.com/rust-lang/rust/commit/1954756aa53d03e59e40669eaa47a15d8497c352 I'll add it to 1.48.0 after some basic testing. (In reply to Georgy Yakovlev from comment #9) > upstream merged a revert > > https://github.com/rust-lang/rust/commit/ > 1954756aa53d03e59e40669eaa47a15d8497c352 > > I'll add it to 1.48.0 after some basic testing. Any success? Patch didn't seem to work (for me) when I tried, not that I really took the time to look at this to be sure. Using rust-1.49.0 (and system-llvm-11.0.1), rust-1.49.0 still fails to build itself with -Ctarget-cpu=skylake, and so does building librsvg. Both are fine without defining target-cpu May need more testing but can't reproduce anymore with rust-1.50.0. Tried rust-bin-1.50.0 and rust-1.50.0[system-llvm] (11.1.0) Reverted to rust-bin-1.49.0 to verify and it still segfaults building librsvg with -Ctarget-cpu=skylake. (In reply to Ostashevskyi Viktor from comment #10) > (In reply to Georgy Yakovlev from comment #9) > > upstream merged a revert > > > > https://github.com/rust-lang/rust/commit/ > > 1954756aa53d03e59e40669eaa47a15d8497c352 > > > > I'll add it to 1.48.0 after some basic testing. > > Any success? nope, it was still segfaulting so maybe the solution is elsewhere, I could not find it. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=70a3fbd29c2a3cfc4a831444d77cc25f155cc268 commit 70a3fbd29c2a3cfc4a831444d77cc25f155cc268 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-04-03 21:00:48 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-04-04 22:08:01 +0000 profiles/info_pkgs: print rust{,-bin} versions Bug: https://bugs.gentoo.org/756340 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> profiles/info_pkgs | 2 ++ 1 file changed, 2 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=925d9532b80e6984d848fef0734b15f463a75d1d commit 925d9532b80e6984d848fef0734b15f463a75d1d Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-04-03 20:58:12 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-04-04 22:08:01 +0000 profiles/info_vars: print RUSTFLAGS as well Bug: https://bugs.gentoo.org/756340 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> profiles/info_vars | 1 + 1 file changed, 1 insertion(+) It seems starting with 1.65.0 this is back while using it as bootstrap to build on a machine without SSE2 while using the default RUSTFLAGS. When using the commands: 1. git clone https://github.com/rust-lang/rust 2. cd rust 3. git checkout 1.65.0 4. git submodule update --init --recursive It seems to force to build itself in debug mode as setting: [rust] channel = "stable" in config.toml no longer seems to work. I'll test reducing the optimisations on the target machine to see if it has any success once set. |