unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Desktops on non-x86_64 systems
Date: Wed, 01 Dec 2021 18:49:59 +0100	[thread overview]
Message-ID: <87mtlkz03c.fsf@gnu.org> (raw)
In-Reply-To: <87pmqghqiy.fsf@gmail.com> (Maxim Cournoyer's message of "Tue, 30 Nov 2021 23:56:21 -0500")

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.

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.

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.

How long is the road ahead in your opinion?

Thanks for working on it!

Ludo’.


  reply	other threads:[~2021-12-01 17:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-27 22:36 Desktops on non-x86_64 systems Ludovic Courtès
2021-11-27 22:43 ` Ricardo Wurmus
2021-11-28  3:05   ` Maxim Cournoyer
2021-11-28  3:28     ` Maxim Cournoyer
2021-11-28  3:43       ` John Soo
2021-11-28  7:29         ` Tobias Platen
2021-11-28  8:57           ` Ricardo Wurmus
2021-11-28 17:49       ` Ludovic Courtès
2021-11-28 18:15         ` Ricardo Wurmus
2021-11-30 15:36           ` Maxim Cournoyer
2021-12-06 12:38             ` Ludovic Courtès
2021-12-01  4:56         ` Maxim Cournoyer
2021-12-01 17:49           ` Ludovic Courtès [this message]
2021-12-01 19:37             ` Maxim Cournoyer
2021-12-02  3:26             ` Maxim Cournoyer
2021-12-06  2:18             ` Maxim Cournoyer
2021-12-06 12:30               ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mtlkz03c.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).