Re: Desktops on non-x86_64 systems

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi again, Ludovic et al!

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

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> I've updated the branch wip-cross-built-rust; it seems to build and run
>> OK (although running the binary produced by compiling hello.rs 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 ftp.gnu.org).

> What we’d need to do is “cut the dependency graph” at the architecture
> boundary, similar to what’s described in
> <https://guix.gnu.org/manual/devel/en/html_node/Porting.html>.
>
> Concretely, we’d cross-build Rust for i686 once; we’d put it in a
> tarball, store it at ftp.gnu.org, 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 ftp.gnu.org 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.

Thanks,

Maxim