[Top][All Lists]

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

Re: Desktops on non-x86_64 systems

From: Ludovic Courtès
Subject: Re: Desktops on non-x86_64 systems
Date: Mon, 06 Dec 2021 13:30:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi Maxim,

Maxim Cournoyer <> 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

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

Thanks for digging this deep into this!



reply via email to

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