[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Desktops on non-x86_64 systems

From: Maxim Cournoyer
Subject: Re: Desktops on non-x86_64 systems
Date: Wed, 01 Dec 2021 22:26:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi again, Ludovic et al!

I'm trying another direction in my reply here based on recent findings;

Ludovic Courtès <> writes:

> Hi!
> Maxim Cournoyer <> skribis:
>> I've updated the branch wip-cross-built-rust; it seems to build and run
>> OK (although running the binary produced by compiling with the
>> cross-built i686-linux rustc in a 32 bit VM took 47 sec (!?)),
>> apparently hanging on something before outputting correctly the message
>> and exiting with 0.
>> I'd now like to figure out the top-level plumbing required to get this
>> rust-i686-linux x86-64 package accepted in the real of i686-linux
>> packages (cross the architecture boundary).  Is this even possible in
>> Guix?
>> In other words, I'd like the i686 architecture to be able to use this
>> rust-i686-linux cross built from x86_64 as if it was a *native* package.
> It’s not possible as it would imply that i686 is able to run x86_64
> code.

Does it?  Since the package was cross-compiled, the resulting binary is
executable on i686 (and dynamically linked to other cross-compiled
shared libraries which are executable there as well) -- it seems natural
that a cross-compiled binary for architecture X should be allowed to
become a part in the dependency graph of a package on that architecture.
I understand that an i686-linux machine wouldn't be able to fully
bootstrap itself -- it would rely on a x86_64-linux machine (either via
offloading or pre-built substitutes) to provide the cross-compiled
rustc; inconvenient, but preferable to some arbitrary binary blob
fetched from the internet (and not that different from using a bootstrap
binary from

> What we’d need to do is “cut the dependency graph” at the architecture
> boundary, similar to what’s described in
> <>.
> Concretely, we’d cross-build Rust for i686 once; we’d put it in a
> tarball, store it at, and make the rust 1.54 package (or
> whatever that is) be equal so that tarball, unpacked, when the current
> system is i686.  (Similar to the ‘guile-bootstrap’ package.)
> It does mean that the cross-built Rust must be statically linked.

The above is a show stopper for rustc, I just learned.  Rust has this
feature called proc macros (procedural macros) that are implemented as
dynamic libraries; and it's a rather core feature, used by the main
serialization/deserialization facilities in Rust (and needed by rustc to
bootstrap itself).  So a statically linked rustc appears near-useless.

> To reduce the risks associated with binary blobs, the Rust build should
> ideally be reproducible, so that anyone can verify that the thing we put
> at is indeed Rust as cross-compiled from x86_64.

Reproducibility should not be an issue; our rust bootstrap chain is
reproducible, except perhaps for the first mrustc-produced 1.40 rust.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]