Re: Desktops on non-x86_64 systems

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> I've refreshed the branch again, and now there are no performance
> problems with the cross-built rustc.
>
> But Ludovic mentioned that the binary would need to be statically linked
> rather than dynamically linked, and in the case of rustc that
> complicates things because it relies on dynamic linkage for its
> procedural macros, a feature it uses and thus requires to build itself.

Bah, too bad.

> It could perhaps work to 'guix pack' it into a relocatable pack, but
> that'd be fragile and not very clean, compared to a statically link
> archive.
>
> The road ahead is
>
> 1. Try to 'cargo expand' the crates that use other proc macros crates,
> and de-register the proc-macros crates from the rust sources.  Rust
> bundles about 40 proc-macros crates.  That's not guaranteed to work
> easily, unfortunately, as 'cargo expand' is a lossy process and not
> guaranteed to be correct.
>
> 2. Supposing 1 works, it should be possible to build a statically linked
> rust/cargo.
>
> If the above fail or is too difficult to achieve, we could explore a
> 'guix pack'-based solution.

We could try option #2 ‘guix pack -RR’.  However it seems that it’d
still be a looong road before we have a usable bootstrap binary of Rust.

Option #1 seems even trickier (though I next to nothing about Rust).

I think our energy would be better spend on trying the latest mrustc and
the proposed i686 “fixes”¹, or, as a longer-term solution, trying
GCC-Rust.

Anyhow, my (limited) understanding is that there’s no “obvious” solution
in sight, but rather longer-term approaches that need to be tried and
developed.

Thanks for digging this deep into this!

Ludo’.

¹ https://github.com/thepowersgang/mrustc/issues/78#issuecomment-980830551