Hi Maxim, Maxim Cournoyer <maxim.courno...@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
