Hi again, Ludovic et al! I'm trying another direction in my reply here based on recent findings;
Ludovic Courtès <l...@gnu.org> writes: > Hi! > > Maxim Cournoyer <maxim.courno...@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
