powerpc64le: rust build failure is bottleneck for many packages

  • Done
  • quality assurance status badge
Details
3 participants
  • Efraim Flashner
  • Marcel van der Boom
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Marcel van der Boom
Severity
normal

Debbugs page

Marcel van der Boom wrote 3 years ago
(address . bug-guix@gnu.org)
875yioxce6.fsf@van-der-boom.nl
I use a Talos II machine as my daily driver and slowly migrating
as many packages to GUIX along the way. The kernel I am running


For many packages, rust is getting to be the bottleneck as a
dependency that does not build.

From what I can see there's a whole chain of rust dependencies
going back to rust@1.39.0 which then ultimately fails with:


Toggle snippet (31 lines)
(16/112) BUILDING bitflags v1.1.0
> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> rustc-1.39.0-src/vendor/bitflags/src/lib.rs -o
> output/rustc-build/libbitflags-1_1_0.rlib --crate-name bitflags
> --crate-type rlib -C
> emit-depfile=output/rustc-build/libbitflags-1_1_0.rlib.d
> --crate-tag 1_1_0 -g --cfg debug_assertions -O -L output -L
> output/rustc-build --cfg bitflags_const_fn
(17/112) BUILDING cc v1.0.35
> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> rustc-1.39.0-src/vendor/cc/src/lib.rs -o
> output/rustc-build/libcc-1_0_35.rlib --crate-name cc
> --crate-type rlib -C
> emit-depfile=output/rustc-build/libcc-1_0_35.rlib.d --crate-tag
> 1_0_35 -g --cfg debug_assertions -O -L output -L
> output/rustc-build
> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> rustc-1.39.0-src/src/librustc_llvm/build.rs --crate-name build
> --crate-type bin -o output/rustc-build/build_rustc_llvm_run -L
> output/rustc-build -g -L output --extern
> build_helper=output/rustc-build/libbuild_helper-0_1_0.rlib
> --extern cc=output/rustc-build/libcc-1_0_35.rlib --edition 2018
> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/output/rustc-build/build_rustc_llvm_run
thread 'main' panicked at 'assertion failed: `(left == right)`
left: `1`,
right: `0`',
rustc-1.39.0-src/vendor/hashbrown/src/raw/mod.rs:1086:59
Process was terminated with signal 6


The line in =mod.rs= points to an assertion in some sort of table
iterator. Way over my head.

I know rust runs on powerpc64le because I have a binary version
1.62 installed through https://archlinuxpower.org/


Is anyone familiar with this working on rust on powerpc64 for the
powerpc64le-linux system?
Maxim Cournoyer wrote 3 years ago
(name . Marcel van der Boom)(address . marcel@van-der-boom.nl)(address . 57303-done@debbugs.gnu.org)
87tu68hu28.fsf@gmail.com
tags 57303 +notabug
thanks

Hi!

Marcel van der Boom <marcel@van-der-boom.nl> writes:

Toggle quote (4 lines)
> I use a Talos II machine as my daily driver and slowly migrating
> as many packages to GUIX along the way. The kernel I am running
> comes fromm https://archlinuxpower.org/

Cool!

Toggle quote (39 lines)
> For many packages, rust is getting to be the bottleneck as a
> dependency that does not build.
>
>>From what I can see there's a whole chain of rust dependencies
> going back to rust@1.39.0 which then ultimately fails with:
>
> (16/112) BUILDING bitflags v1.1.0
>> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
>> rustc-1.39.0-src/vendor/bitflags/src/lib.rs -o
>> output/rustc-build/libbitflags-1_1_0.rlib --crate-name bitflags
>> --crate-type rlib -C
>> emit-depfile=output/rustc-build/libbitflags-1_1_0.rlib.d
>> --crate-tag 1_1_0 -g --cfg debug_assertions -O -L output -L
>> output/rustc-build --cfg bitflags_const_fn
> (17/112) BUILDING cc v1.0.35
>> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
>> rustc-1.39.0-src/vendor/cc/src/lib.rs -o
>> output/rustc-build/libcc-1_0_35.rlib --crate-name cc
>> --crate-type rlib -C
>> emit-depfile=output/rustc-build/libcc-1_0_35.rlib.d --crate-tag
>> 1_0_35 -g --cfg debug_assertions -O -L output -L
>> output/rustc-build
>> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
>> rustc-1.39.0-src/src/librustc_llvm/build.rs --crate-name build
>> --crate-type bin -o output/rustc-build/build_rustc_llvm_run -L
>> output/rustc-build -g -L output --extern
>> build_helper=output/rustc-build/libbuild_helper-0_1_0.rlib
>> --extern cc=output/rustc-build/libcc-1_0_35.rlib --edition 2018
>> /tmp/guix-build-rust-1.39.0.drv-0/mrustc/output/rustc-build/build_rustc_llvm_run
> thread 'main' panicked at 'assertion failed: `(left == right)`
> left: `1`,
> right: `0`',
> rustc-1.39.0-src/vendor/hashbrown/src/raw/mod.rs:1086:59
> Process was terminated with signal 6
>
>
> The line in =mod.rs= points to an assertion in some sort of table
> iterator. Way over my head.

Working only on x86_64 is a limitation of mrustc, which is used to
bootstrap rust cleanly from sources on Guix.

Toggle quote (3 lines)
> I know rust runs on powerpc64le because I have a binary version
> 1.62 installed through https://archlinuxpower.org/

Yes, Rust itself is not the problem, but its bootstrap.

I'd suggest lending a hand to mrustc to iron out issues like this or
request to Rust upstream support for bootstrapping for sources.
Investigating future alternatives such as GCC Rust or other similar
efforts could be useful for the time they are ripe to use, too.

Closing, as there's not much we can do on Guix's side.

Thanks,

Maxim
Closed
Efraim Flashner wrote 3 years ago
(name . Marcel van der Boom)(address . marcel@van-der-boom.nl)(address . 57303@debbugs.gnu.org)
YwNECs5Uk2rWhBwE@3900XT
On Fri, Aug 19, 2022 at 08:56:10PM +0200, Marcel van der Boom wrote:
Toggle quote (52 lines)
>
> I use a Talos II machine as my daily driver and slowly migrating as many
> packages to GUIX along the way. The kernel I am running comes fromm
> https://archlinuxpower.org/
>
>
> For many packages, rust is getting to be the bottleneck as a dependency that
> does not build.
>
> From what I can see there's a whole chain of rust dependencies going back to
> rust@1.39.0 which then ultimately fails with:
>
>
> --8<---------------cut here---------------start------------->8---
> (16/112) BUILDING bitflags v1.1.0
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> > rustc-1.39.0-src/vendor/bitflags/src/lib.rs -o
> > output/rustc-build/libbitflags-1_1_0.rlib --crate-name bitflags
> > --crate-type rlib -C
> > emit-depfile=output/rustc-build/libbitflags-1_1_0.rlib.d --crate-tag
> > 1_1_0 -g --cfg debug_assertions -O -L output -L output/rustc-build --cfg
> > bitflags_const_fn
> (17/112) BUILDING cc v1.0.35
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> > rustc-1.39.0-src/vendor/cc/src/lib.rs -o
> > output/rustc-build/libcc-1_0_35.rlib --crate-name cc --crate-type rlib
> > -C emit-depfile=output/rustc-build/libcc-1_0_35.rlib.d --crate-tag
> > 1_0_35 -g --cfg debug_assertions -O -L output -L output/rustc-build
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> > rustc-1.39.0-src/src/librustc_llvm/build.rs --crate-name build
> > --crate-type bin -o output/rustc-build/build_rustc_llvm_run -L
> > output/rustc-build -g -L output --extern
> > build_helper=output/rustc-build/libbuild_helper-0_1_0.rlib --extern
> > cc=output/rustc-build/libcc-1_0_35.rlib --edition 2018
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/output/rustc-build/build_rustc_llvm_run
> thread 'main' panicked at 'assertion failed: `(left == right)`
> left: `1`,
> right: `0`', rustc-1.39.0-src/vendor/hashbrown/src/raw/mod.rs:1086:59
> Process was terminated with signal 6
> --8<---------------cut here---------------end--------------->8---
>
>
> The line in =mod.rs= points to an assertion in some sort of table iterator.
> Way over my head.
>
> I know rust runs on powerpc64le because I have a binary version 1.62
> installed through https://archlinuxpower.org/
>
>
> Is anyone familiar with this working on rust on powerpc64 for the
> powerpc64le-linux system?

About 2 months ago I spent some time and got the rust bootstrap working
for riscv64-linux. I would suggest looking at the staging branch since
there the rust bootstrap version is at 1.54.

--
Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmMDRAYACgkQQarn3Mo9
g1EFjg//XfJwp51WEmqzPK69SYIg1FcQvjM0i3mW04twBe8ZqYI04ZIGLUHloFj0
mpE2rroEl/QV0M18ZvF3vZiHZ3fZdvqVLrOY31gS6yUceRZm8h0PsBHMT2ykRIrz
t8g8jOMaD8Ms644RpeoqoQBq94uuvMppsJaZvg4ModOd7EVDNFOSelfSeXqm4Ed2
yBopZL/qv2u3Shw6X2QFzuu65cMLV1RoGJiPOvBsp8rr2PckTOCZx6FuZYnLCGYF
mZPnGuPeYNdB9DpP6z8OA8KrRm/ceHRa+GUMArx4m0AwFoFKBdcqcKAfphUADBGv
82TxrE0N2XX7LkuPNFtZ3Ymm0zpd0yH3zV6rdgHQYivgK/IlN3weZw/ATimMPVpl
tPGBbFHDYLgbvmkwr0jQsdA5cBfOuvlQ7COWf32wLA8+j018oAYQF2zy1mF1v8QW
odsavpd2q6ltJX96ao0bbHu4yIwIqXItvVI04/WCWZthdWFnL+LZGR6WjUzmpLxl
m3JVdSjUoANoVQ7QOIDjlxh//yVGjE5Vl01wB5YJYgQH07r9m7h9dQcQOx2IWetd
B5ad43M2jTRR6kGggXBDEE3rP0eKMH5QJyt7RtjnhONpJgLtY6SsK68+ewMtMU0i
xF6Nrj+4t1jLYvAVHya4LnOCEmP1qF+8OJGsnTKebxaVzLqjivE=
=res8
-----END PGP SIGNATURE-----


Marcel van der Boom wrote 3 years ago
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 57303@debbugs.gnu.org)
87fsholk73.fsf@van-der-boom.nl
[Efraim Flashner]:
Toggle quote (10 lines)
>> Is anyone familiar with this working on rust on powerpc64 for
>> the
>> powerpc64le-linux system?

> About 2 months ago I spent some time and got the rust bootstrap
> working
> for riscv64-linux. I would suggest looking at the staging branch
> since
> there the rust bootstrap version is at 1.54.

Ah, I didn't even think of that, thanks! Will try that.
Marcel van der Boom wrote 3 years ago
(name . Efraim Flashner)(address . efraim@flashner.co.il)(address . 57303@debbugs.gnu.org)
87ilmj5met.fsf@van-der-boom.nl
[Marcel van der Boom]:
Toggle quote (9 lines)
> [Efraim Flashner]:
>> About 2 months ago I spent some time and got the rust bootstrap
>> working
>> for riscv64-linux. I would suggest looking at the staging
>> branch since
>> there the rust bootstrap version is at 1.54.

> Ah, I didn't even think of that, thanks! Will try that.

Unfortunately, it fails with the exact same error
?
Your comment

This issue is archived.

To comment on this conversation send an email to 57303@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 57303
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help