Desktops on non-x86_64 systems

Desktops on non-x86_64 systems

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Hello Guix!

As you may know, librsvg 2.50 on ‘core-updates-frozen’ depends on Rust.
However mrustc, which we use to build the first Rust compiler, currently
only works on x86_64.  This means that ~28% of the packages on
‘core-updates-frozen’ are x86_64-only (vs. ~15% on ‘master’).

Among these, the most problematic missing packages are desktop
environments: Xfce, GNOME, etc.  So far our “pledge”, encoded in
‘etc/release-manifest.scm’, was that all the desktop environments would
be available on x86_64 and i686, so that one could install Guix System
just the same way on both.  Currently this is no longer possible on
‘core-updates-frozen’, and I think that’s a problem.

The patch below does something unorthodox: it reintroduces librsvg 2.40
(written in C) and uses it selectively so we can have a desktop
environment with Xfce on i686.  It’s not enough to get GDM though;
there’s a couple of GNOME packages that depend on librsvg and I haven’t
checked whether they work with the old librsvg.

I think that’s the most realistic way to salvage desktops on i686 for
now.  In the future mrustc may well support i686¹, or perhaps GCC-Rust
will be mature enough to replace mrustc, but in both cases we’re talking
about a longer time frame.

What do people think?

Thanks,
Ludo’.

¹ https://github.com/thepowersgang/mrustc/issues/78


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 7242 bytes --]

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 8e0e750180..cc7fadfe91 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -3617,6 +3617,79 @@ (define-public librsvg
     (home-page "https://wiki.gnome.org/LibRsvg")
     (license license:lgpl2.1+)))
 
+(define-public librsvg-2.40
+  ;; This is the last version implemented in C.
+  (package
+    (inherit librsvg)
+    (version "2.40.21")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "mirror://gnome/sources/librsvg/"
+                                  (version-major+minor version)
+                                  "/librsvg-" version ".tar.xz"))
+              (sha256
+               (base32
+                "1fljkag2gr7c4k5mn798lgf9903xslz8h51bgvl89nnay42qjqpp"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:configure-flags (list "--disable-static")
+       #:phases
+       (modify-phases %standard-phases
+         (add-before 'configure 'pre-configure
+           (lambda* (#:key inputs #:allow-other-keys)
+             (substitute* "gdk-pixbuf-loader/Makefile.in"
+               ;; By default the gdk-pixbuf loader is installed under
+               ;; gdk-pixbuf's prefix.  Work around that.
+               (("gdk_pixbuf_moduledir = .*$")
+                (string-append "gdk_pixbuf_moduledir = "
+                               "$(prefix)/lib/gdk-pixbuf-2.0/2.10.0/"
+                                "loaders\n"))
+               ;; Drop the 'loaders.cache' file, it's in gdk-pixbuf+svg.
+               (("gdk_pixbuf_cache_file = .*$")
+                "gdk_pixbuf_cache_file = $(TMPDIR)/loaders.cache\n"))
+             #t))
+         (add-before 'check 'remove-failing-tests
+           (lambda _
+             (with-directory-excursion "tests/fixtures/reftests"
+               (for-each delete-file
+                         '(;; This test fails on i686:
+                           "svg1.1/masking-path-04-b.svg"
+                           ;; This test fails on armhf:
+                           "svg1.1/masking-mask-01-b.svg"
+                           ;; This test fails on aarch64:
+                           "bugs/777834-empty-text-children.svg")))
+             #t)))))
+    (native-inputs
+     `(("pkg-config" ,pkg-config)
+       ("glib" ,glib "bin")                               ; glib-mkenums, etc.
+       ("gobject-introspection" ,gobject-introspection))) ; g-ir-compiler, etc.
+    (inputs
+     `(;; XXX: 1.44 causes some test failures, so we stick with 1.42 for
+       ;; this ancient version of librsvg.
+       ("pango" ,pango-1.42)
+       ("libcroco" ,libcroco)
+       ("bzip2" ,bzip2)
+       ("libgsf" ,libgsf)
+       ("libxml2" ,libxml2)))
+    (propagated-inputs
+     ;; librsvg-2.0.pc refers to all of that.
+     `(("cairo" ,cairo)
+       ("gdk-pixbuf" ,gdk-pixbuf)
+       ("glib" ,glib)))
+    (synopsis "Render SVG files using Cairo (ancient C version)")
+    (properties '((hidden? . #t)))))
+
+(define* (librsvg-for-system #:optional
+                             (system (or (%current-target-system)
+                                         (%current-system))))
+  ;; Since librsvg 2.50 depends on Rust, and Rust is only correctly support on
+  ;; x86_64, use the ancient C version on other platforms.
+  (if (string-prefix? "x86_64-" system)
+      librsvg
+      librsvg-2.40))
+
+(export librsvg-for-system)
+
 (define-public libidl
   (package
     (name "libidl")
@@ -5538,7 +5611,10 @@ (define-public upower
        #:configure-flags (list "--localstatedir=/var"
                                (string-append "--with-udevrulesdir="
                                               (assoc-ref %outputs "out")
-                                              "/lib/udev/rules.d"))))
+                                              "/lib/udev/rules.d"))
+
+       ;; FIXME: Test failure on i686-linux.
+       #:tests? #f))
     (native-inputs
      `(("autoconf" ,autoconf)
        ("automake" ,automake)
@@ -8865,7 +8941,7 @@ (define-public gnome-shell
        ("evolution-data-server" ,evolution-data-server)
        ("gcr" ,gcr)
        ("gdm" ,gdm)
-       ("librsvg" ,librsvg)
+       ;; ("librsvg" ,librsvg)
        ("gjs" ,gjs)
        ("gtk" ,gtk)
        ("gnome-autoar" ,gnome-autoar)
@@ -8892,7 +8968,7 @@ (define-public gnome-shell
        ("upower" ,upower)
        ;; XXX: These requirements were added in 3.24, but no mention in NEWS.
        ;; Missing propagation? See also: <https://bugs.gnu.org/27264>
-       ("librsvg" ,librsvg)
+       ;; ("librsvg" ,librsvg)
        ("geoclue" ,geoclue)))
     (synopsis "Desktop shell for GNOME")
     (home-page "https://wiki.gnome.org/Projects/GnomeShell")
diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index 35a992dcf7..7ea5f19a8d 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -681,7 +681,7 @@ (define-public gst-plugins-good
        ("bzip2" ,bzip2)
        ("cairo" ,cairo)
        ("flac" ,flac)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,(librsvg-for-system))
        ("glib" ,glib)
        ("glib-networking" ,glib-networking)
        ("glu" ,glu)
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index e8ac0b79bb..b69fa372d9 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -1417,7 +1417,7 @@ (define-public guile-rsvg
                        ("libtool" ,libtool)
                        ("texinfo" ,texinfo)))
       (inputs `(("guile" ,guile-3.0)
-                ("librsvg" ,librsvg)
+                ("librsvg" ,(librsvg-for-system))
                 ("guile-lib" ,guile-lib)))        ;for (unit-test)
       (propagated-inputs `(("guile-cairo" ,guile-cairo)))
       (synopsis "Render SVG images using Cairo from Guile")
diff --git a/gnu/packages/xfce.scm b/gnu/packages/xfce.scm
index 06f3e3aabc..a63676a04b 100644
--- a/gnu/packages/xfce.scm
+++ b/gnu/packages/xfce.scm
@@ -633,7 +633,7 @@ (define-public xfce4-xkb-plugin
        ("pkg-config" ,pkg-config)))
     (inputs
      `(("garcon" ,garcon)
-       ("librsvg" ,librsvg)
+       ("librsvg" ,(librsvg-for-system))
        ("libwnck" ,libwnck)
        ("libx11" ,libx11)
        ("libxfce4ui" ,libxfce4ui)
diff --git a/gnu/system/examples/lightweight-desktop.tmpl b/gnu/system/examples/lightweight-desktop.tmpl
index d4330ecc8e..510db263f5 100644
--- a/gnu/system/examples/lightweight-desktop.tmpl
+++ b/gnu/system/examples/lightweight-desktop.tmpl
@@ -3,7 +3,7 @@
 ;; environments.
 
 (use-modules (gnu) (gnu system nss))
-(use-service-modules desktop)
+(use-service-modules desktop sddm xorg)
 (use-package-modules bootloaders certs emacs emacs-xyz ratpoison suckless wm
                      xorg)
 
@@ -53,7 +53,12 @@
 
   ;; Use the "desktop" services, which include the X11
   ;; log-in service, networking with NetworkManager, and more.
-  (services %desktop-services)
+  ;; Remove the GDM service and use the SDDM display manager
+  ;; instead.
+  (services
+   (modify-services (append (list (service sddm-service-type))
+                        %desktop-services)
+     (delete gdm-service-type)))
 
   ;; Allow resolution of '.local' host names with mDNS.
   (name-service-switch %mdns-host-lookup-nss))

Re: Desktops on non-x86_64 systems

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> As you may know, librsvg 2.50 on ‘core-updates-frozen’ depends 
> on Rust.
> However mrustc, which we use to build the first Rust compiler, 
> currently
> only works on x86_64.  This means that ~28% of the packages on
> ‘core-updates-frozen’ are x86_64-only (vs. ~15% on ‘master’).
>
> Among these, the most problematic missing packages are desktop
> environments: Xfce, GNOME, etc.  So far our “pledge”, encoded in
> ‘etc/release-manifest.scm’, was that all the desktop 
> environments would
> be available on x86_64 and i686, so that one could install Guix 
> System
> just the same way on both.  Currently this is no longer possible 
> on
> ‘core-updates-frozen’, and I think that’s a problem.
>
> The patch below does something unorthodox: it reintroduces 
> librsvg 2.40
> (written in C) and uses it selectively so we can have a desktop
> environment with Xfce on i686.  It’s not enough to get GDM 
> though;
> there’s a couple of GNOME packages that depend on librsvg and I 
> haven’t
> checked whether they work with the old librsvg.

There is also the unpleasant option to introduce a rust binary for 
architectures other than x86_64, because we can’t bootstrap it 
there.  It should be noted that this would not be unprecedented. 
We have bootstrap binaries for some compilers such as Free Pascal 
or GHC.

Adding an old version of librsvg is not obviously the better 
option.

-- 
Ricardo

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> As you may know, librsvg 2.50 on ‘core-updates-frozen’ depends on
>> Rust.
>> However mrustc, which we use to build the first Rust compiler,
>> currently
>> only works on x86_64.  This means that ~28% of the packages on
>> ‘core-updates-frozen’ are x86_64-only (vs. ~15% on ‘master’).
>>
>> Among these, the most problematic missing packages are desktop
>> environments: Xfce, GNOME, etc.  So far our “pledge”, encoded in
>> ‘etc/release-manifest.scm’, was that all the desktop environments
>> would
>> be available on x86_64 and i686, so that one could install Guix
>> System
>> just the same way on both.  Currently this is no longer possible on
>> ‘core-updates-frozen’, and I think that’s a problem.
>>
>> The patch below does something unorthodox: it reintroduces librsvg
>> 2.40
>> (written in C) and uses it selectively so we can have a desktop
>> environment with Xfce on i686.  It’s not enough to get GDM though;
>> there’s a couple of GNOME packages that depend on librsvg and I
>> haven’t
>> checked whether they work with the old librsvg.
>
> There is also the unpleasant option to introduce a rust binary for
> architectures other than x86_64, because we can’t bootstrap it 
> there.  It should be noted that this would not be unprecedented. We
> have bootstrap binaries for some compilers such as Free Pascal or GHC.
>
> Adding an old version of librsvg is not obviously the better option.

I agree with Ricardo here.  We've tried hard to get Rust bootstrapped,
but that is only viable for x86_64 so far.  When bootstrapping is not
possible, there is already a precedent of using bootstrap binaries as
Ricardo pointed out.  So it seems that Rust falls into this category for
now.

It'd be much easier in my opinion to do so than trying to get GNOME to
build an obsolete versions that it will reject without us going at
length with it (not to mention the security vulnerabilities that'd need
to be patched by our own).  With mrustc and gcc-rust improving quickly,
hopefully that'd be a temporary solution.

I'll still try to get mrustc to build on i686 by specifying -O0 to gcc
while it builds it, to see if the memory usage can be brought below the
4 GiB limit.

Thanks,

Maxim

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hello again,

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

[...]

>> There is also the unpleasant option to introduce a rust binary for
>> architectures other than x86_64, because we can’t bootstrap it 
>> there.  It should be noted that this would not be unprecedented. We
>> have bootstrap binaries for some compilers such as Free Pascal or GHC.
>>
>> Adding an old version of librsvg is not obviously the better option.
>
> I agree with Ricardo here.  We've tried hard to get Rust bootstrapped,
> but that is only viable for x86_64 so far.  When bootstrapping is not
> possible, there is already a precedent of using bootstrap binaries as
> Ricardo pointed out.  So it seems that Rust falls into this category for
> now.
>
> It'd be much easier in my opinion to do so than trying to get GNOME to
> build an obsolete versions that it will reject without us going at
> length with it (not to mention the security vulnerabilities that'd need
> to be patched by our own).  With mrustc and gcc-rust improving quickly,
> hopefully that'd be a temporary solution.

I'd like to revise my position, as I got confirmation that it ought to
be possible to cross-build rustc for other architectures from our
(cleanly bootstrapped) x86_64 rustc!

Here's a transcript of my question on #mrustc (libera.chat):

--8<---------------cut here---------------start------------->8---
00:36:38  apteryx | hello!  Can rustc cross-compile itself and its stdlib for another architecture?                                                                                           
00:37:13  apteryx | in other words; is it possible to have a clean bootstrapped rust (via mrustc) on all architectures although mrustc currently only support x86_64?                         
02:27:53  Mutabah | yes                                                                                                                                                                       
04:28:27 clemens3 | fyi: http://techinvest.li/tinux/#rustc                                                                                                                                    
04:28:38 clemens3 | which uses and bundles mrustc                                                                                                                                             
04:29:05 clemens3 | happy to now upstream my little changes, mostly based on the Test.. build.sh and readme.txt..
--8<---------------cut here---------------end--------------->8---

I haven't yet done any reading, but if Mutabah (the author of mrustc)
says it's possible, I believe it!

Cheers,

Maxim

Re: Desktops on non-x86_64 systems

[John Soo]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]

Hi Guix,

I had the same thought as Maxim. In my quest for arm support for ghc, I thought about using a cross-compiled version. Is this possible or even desirable? I think for rust and ghc it would be very helpful - if somewhat less principled than a bootstrap all the way up (on the same computer).

I'm curious what the consensus is here.

Kindly,

John


[-- Attachment #2: Type: text/html, Size: 721 bytes --]

Re: Desktops on non-x86_64 systems

[Tobias Platen]

On Sat, 2021-11-27 at 19:43 -0800, John Soo wrote:
> Hi Guix,
> 
> I had the same thought as Maxim. In my quest for arm support for ghc,
> I thought about using a cross-compiled version. Is this possible or
> even desirable?  I think for rust and ghc it would be very helpful -
> if somewhat less principled than a bootstrap all the way up (on the
> same computer).
> 
> I'm curious what the consensus is here.
> 
> Kindly,
> 
> John
> 
>  
I have a Talos II, on which I have rust running. But that one is not in
Debian or GUIX, it uses its own installer. Rust is needed for the
power-instruction-analyzer and Kazan (a Vulkan implementation). Both
are part of the libre-soc project. https://libre-soc.org/

Tobias

Re: Desktops on non-x86_64 systems

[Ricardo Wurmus]

Tobias Platen <guix@platen-software.de> writes:

> On Sat, 2021-11-27 at 19:43 -0800, John Soo wrote:
>> Hi Guix,
>> 
>> I had the same thought as Maxim. In my quest for arm support 
>> for ghc,
>> I thought about using a cross-compiled version. Is this 
>> possible or
>> even desirable?  I think for rust and ghc it would be very 
>> helpful -
>> if somewhat less principled than a bootstrap all the way up (on 
>> the
>> same computer).
>> 
>> I'm curious what the consensus is here.
>> 
>> Kindly,
>> 
>> John
>> 
>>  
> I have a Talos II, on which I have rust running. But that one is 
> not in
> Debian or GUIX, it uses its own installer.

How was it bootstrapped?

-- 
Ricardo

Re: Desktops on non-x86_64 systems

[Ludovic Courtès]

Hi,

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

> I'd like to revise my position, as I got confirmation that it ought to
> be possible to cross-build rustc for other architectures from our
> (cleanly bootstrapped) x86_64 rustc!

[...]

> I haven't yet done any reading, but if Mutabah (the author of mrustc)
> says it's possible, I believe it!

I suspect there’s a difference between “it’s possible” and “we’ve
successfully cross-compiled Rust.”  :-)

We could try that, but IMO we first need a solution within days—we just
cannot reasonably let this branch go on for longer than that.  The
librsvg 2.40 hack would give us Xfce (maybe GNOME?) on i686 today.

Perhaps we can address all this in several steps:

  1. apply the librsvg 2.40 hack now so we can merge
     ‘core-updates-frozen’ this week for real;

  2. later on, introduce some Rust binary for non-x86_64; that would
     lead to rebuilds only on those architectures;

  3. eventually, update mrustc (and have it call gcc with -O0 to reduce
     its memory footprint), or use GCC-Rust instead of that’s viable.

WDYT?

I think we agree on the strategy and just need to agree on tactics.
:-)

Thanks,
Ludo’.

Re: Desktops on non-x86_64 systems

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> We could try that, but IMO we first need a solution within 
> days—we just
> cannot reasonably let this branch go on for longer than that. 
> The
> librsvg 2.40 hack would give us Xfce (maybe GNOME?) on i686 
> today.
>
> Perhaps we can address all this in several steps:
>
>   1. apply the librsvg 2.40 hack now so we can merge
>      ‘core-updates-frozen’ this week for real;
>
>   2. later on, introduce some Rust binary for non-x86_64; that 
>   would
>      lead to rebuilds only on those architectures;
>
>   3. eventually, update mrustc (and have it call gcc with -O0 to 
>   reduce
>      its memory footprint), or use GCC-Rust instead of that’s 
>      viable.
>
> WDYT?

This sounds sensible.  Merging core-updates-frozen does *not* mean 
that it needs to be ready for release.  It’s been delayed for too 
long and further delays just serve to taint our morale and drain 
our energy, applying fixes again and again with no end in sight.

These ongoing delays have made core-updates-frozen grow so much in 
scope that we cannot afford to delay a merge any longer.  Let’s 
merge asap, even if that means using an older librsvg right now. 
Then add rust for non-x86_64 — either by cross-building it 
ourselves or getting an existing binary to restore feature parity. 
Then work on a long-term solution.


-- 
Ricardo

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hello,

Ricardo Wurmus <rekado@elephly.net> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> We could try that, but IMO we first need a solution within days—we
>> just
>> cannot reasonably let this branch go on for longer than that. The
>> librsvg 2.40 hack would give us Xfce (maybe GNOME?) on i686 today.
>>
>> Perhaps we can address all this in several steps:
>>
>>   1. apply the librsvg 2.40 hack now so we can merge
>>      ‘core-updates-frozen’ this week for real;
>>
>>   2. later on, introduce some Rust binary for non-x86_64; that
>> would
>>      lead to rebuilds only on those architectures;
>>
>>   3. eventually, update mrustc (and have it call gcc with -O0 to
>> reduce
>>      its memory footprint), or use GCC-Rust instead of that’s
>> viable.
>>
>> WDYT?
>
> This sounds sensible.  Merging core-updates-frozen does *not* mean
> that it needs to be ready for release.  It’s been delayed for too 
> long and further delays just serve to taint our morale and drain our
> energy, applying fixes again and again with no end in sight.
>
> These ongoing delays have made core-updates-frozen grow so much in
> scope that we cannot afford to delay a merge any longer.  Let’s 
> merge asap, even if that means using an older librsvg right now. Then
> add rust for non-x86_64 — either by cross-building it ourselves or
> getting an existing binary to restore feature parity. Then work on a
> long-term solution.

I hear your frustration w.r.t to delays; I don't mind if this stopgap
solution is implemented *now*, but I'm skeptical that it'd allow GNOME
to built.

I've been experimenting with a cross-compiled rustc; it's building, but
there are some things to fix (the ld-wrapper used to wrap rustc so far
is the native one, which is incorrect I believe, and cargo doesn't find
the correct libz, libssh2).

The branch is wip-cross-built-rust on our Savannah repo.

I 'guix pack'd rust-i686-linux and tried it on a 32-bit Debian VM:

For rustc:

--8<---------------cut here---------------start------------->8---
$ file /gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/rustc
/gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/rustc: symbolic link to /gnu/store/50fsf4g5xb51qa9jg7xhaaxcwh7h5v2w-rust-i686-linux-1.54.0/bin/rustc

 $ file /gnu/store/50fsf4g5xb51qa9jg7xhaaxcwh7h5v2w-rust-i686-linux-1.54.0/bin/.rustc-real
/gnu/store/50fsf4g5xb51qa9jg7xhaaxcwh7h5v2w-rust-i686-linux-1.54.0/bin/.rustc-real:
ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically
linked, interpreter
/gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/ld-linux.so.2,
for GNU/Linux 2.6.32, stripped

$ /gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/rustc --version
rustc 1.54.0
--8<---------------cut here---------------end--------------->8---

For cargo:

--8<---------------cut here---------------start------------->8---
$ file /gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/cargo
/gnu/store/6fkn8fc0m642xlnbblv3026cpp4i2411-profile/bin/cargo: symbolic link to /gnu/store/vhfdxbxla54n56qggv975c39vyaa0z91-rust-i686-linux-1.54.0-cargo/bin/cargo

$ file /gnu/store/vhfdxbxla54n56qggv975c39vyaa0z91-rust-i686-linux-1.54.0-cargo/bin/cargo
/gnu/store/vhfdxbxla54n56qggv975c39vyaa0z91-rust-i686-linux-1.54.0-cargo/bin/cargo: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/ld-linux.so.2, for GNU/Linux 2.6.32, stripped

$ /gnu/store/vhfdxbxla54n56qggv975c39vyaa0z91-rust-i686-linux-1.54.0-cargo/bin/cargo --version
/gnu/store/vhfdxbxla54n56qggv975c39vyaa0z91-rust-i686-linux-1.54.0-cargo/bin/cargo:
error while loading shared libraries: libz.so: wrong ELF class:
ELFCLASS64

$ ldd /gnu/store/vhfdxbxla54n56qggv975c39vyaa0z91-rust-i686-linux-1.54.0-cargo/bin/cargo 
	linux-gate.so.1 (0xb7f22000)
	libz.so => not found
	libcurl.so.4 => not found
	libssl.so.1.1 => /lib/i386-linux-gnu/libssl.so.1.1 (0xb71ae000)
	libcrypto.so.1.1 => /lib/i386-linux-gnu/libcrypto.so.1.1 (0xb6eeb000)
	libgcc_s.so.1 => /gnu/store/x5y2ngh1asiv3dkcbzaga9ml56xcm3ps-gcc-cross-i686-linux-gnu-10.3.0-lib/lib/gcc/i686-linux-gnu/10.3.0/../../../../i686-linux-gnu/lib/libgcc_s.so.1 (0xb6ecb000)
	libpthread.so.0 => /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/libpthread.so.0 (0xb6eaa000)
	libm.so.6 => /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/libm.so.6 (0xb6da8000)
	libdl.so.2 => /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/libdl.so.2 (0xb6da0000)
	libc.so.6 => /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/libc.so.6 (0xb6bb0000)
	/gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7f24000)
--8<---------------cut here---------------end--------------->8---

To be continued...

Maxim

Re: Desktops on non-x86_64 systems

[Ludovic Courtès]

Hi,

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

>> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>> Perhaps we can address all this in several steps:
>>>
>>>   1. apply the librsvg 2.40 hack now so we can merge
>>>      ‘core-updates-frozen’ this week for real;

[...]

> I hear your frustration w.r.t to delays; I don't mind if this stopgap
> solution is implemented *now*, but I'm skeptical that it'd allow GNOME
> to built.

Status update: there’s now ‘librsvg-for-system’ used in a variety of
places, which selects librsvg 2.40 (in C) on non-x86_64 systems:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen&id=8477a6d743f3068e449402ade739355878242377

It’s used in a number of places, including GTK+, Emacs, Mate, and Xfce:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen&id=2561f2720f6afdab47991e6430dc8a1215a27bc7
  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen&id=3bd7ce60530ad363e235f458ecbe2bcc9454242a
  https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen&id=efbaa5fcc8caeae7228c8f06c13879e7e920f5ea

We can now build Mate and Xfce on i686, with SVG support in GTK+
(without that I suppose they’d be next to unusable because many/most
icons are SVGs these days.)

What we still cannot build is GNOME, and it seems to be out of reach
because gnome → gjs → rust… unless we can use an older GJS or even
Duktape?

It’s a problem because GDM is in ‘%desktop-services’.

Ludo’.

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hello!

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.

Following what was done for polkit-mozjs/polkit-duktape, I've laid the
basic blocks:

--8<---------------cut here---------------start------------->8---
2 files changed, 25 insertions(+), 8 deletions(-)
gnu/packages/rust.scm       | 26 ++++++++++++++++++++------
guix/build-system/cargo.scm |  7 +++++--

modified   gnu/packages/rust.scm
@@ -54,11 +54,13 @@ (define-module (gnu packages rust)
   #:use-module (guix download)
   #:use-module (guix git-download)
   #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix memoization)
   #:use-module (guix packages)
   #:use-module ((guix build utils) #:select (alist-replace))
   #:use-module (guix utils)
   #:use-module (ice-9 match)
-  #:use-module (srfi srfi-26))
+  #:use-module (srfi srfi-26)
+  #:export (rust))
 
 ;; This is the hash for the empty file, and the reason it's relevant is not
 ;; the most obvious.
@@ -780,10 +782,22 @@ (define rust-1.54
                             (package-native-inputs base-rust))))))
 
 ;;; Note: Only the latest versions of Rust are supported and tested.  The
-;;; intermediate rusts are built for bootstrapping purposes and should not
-;;; be relied upon.  This is to ease maintenance and reduce the time
-;;; required to build the full Rust bootstrap chain.
-(define-public rust rust-1.54)
+;;; intermediate rusts are built for bootstrapping purposes and should not be
+;;; relied upon.  This is to ease maintenance and reduce the time required to
+;;; build the full Rust bootstrap chain.
+(define-public rust-x86-64-linux rust-1.54)
+
+(define rust-for-system
+  (mlambda (system)
+    "Return a rust package that can be built for SYSTEM."
+    (if (string-prefix? "i686" system)
+        rust-i686-linux
+        rust-x86-64-linux)))
+
+(define-syntax rust
+  (identifier-syntax (rust-for-system
+                      (or (%current-target-system)
+                          (%current-system)))))
 
 (define (force-system p system)
   (package/inherit p
@@ -796,7 +810,7 @@ (define force-i686 (cut force-system <> "i686-linux"))
 ;;; Rust cross-built for i686-linux.
 ;;; TODO: Make a procedure of it that returns a cross-built rust package.
 (define-public rust-i686-linux
-  (let* ((base-rust (rust-bootstrapped-package rust))
+  (let* ((base-rust (rust-bootstrapped-package rust-x86-64-linux))
          (base-source (package-source base-rust)))
     (package/inherit base-rust
       (source (origin
modified   guix/build-system/cargo.scm
@@ -58,8 +58,11 @@ (define (crate-uri name version)
 (define (default-rust)
   "Return the default Rust package."
   ;; Lazily resolve the binding to avoid a circular dependency.
-  (let ((rust (resolve-interface '(gnu packages rust))))
-    (module-ref rust 'rust)))
+  (let-system (system target)
+    (let ((rust (resolve-interface '(gnu packages rust))))
+      (if (string-prefix? "i686" (or target system))
+          (module-ref rust 'rust-i686-linux)
+          (module-ref rust 'rust-x86-64-linux)))))
 
 (define %cargo-utils-modules
   ;; Build-side modules imported by default.
--8<---------------cut here---------------end--------------->8---

But this doesn't take care of switching the x86_64-associated
rust-i686-linux package to become known as a i686 one.

How to proceed?  I need a wizard :-).

Thanks!

Maxim

Re: Desktops on non-x86_64 systems

[Ludovic Courtès]

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’.

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> 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.)

OK!  Good to know that it's been done before!  Thanks for the pointer.

> It does mean that the cross-built Rust must be statically linked.

OK.  That's probably not too difficult, given the cozy relationship Rust
enjoys with static linking.  Where does this requirement come from
though?  And would we need to use something else than glibc, as IIUC it
cannot be completely statically linked in the produced binaries.

> 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?

I currently have this runtime problem with the build, where the
correctly compiled hello.rs program below:

--8<---------------cut here---------------start------------->8---
$ cat hello.rs 
// This is a comment, and is ignored by the compiler
// You can test this code by clicking the "Run" button over there ->
// This is a comment, and is ignored by the compiler
// You can test this code by clicking the "Run" button over there ->
// or if you prefer to use your keyboard, you can use the "Ctrl + Enter" shortcut

// This code is editable, feel free to hack it!
// You can always return to the original code by clicking the "Reset" button ->

// This is the main function
fn main() {
    // Statements here are executed when the compiled binary is called

    // Print text to the console
    println!("Hello World!");
}

$ time rustc hello.rs

real	0m3.465s
user	0m1.113s
sys	0m1.217s

$ file hello
hello: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=5458fb195357d02ff6de3d429201d69c16f03e1b, for GNU/Linux 2.6.32, with debug_info, not stripped

$ time ./hello
Hello World!

real	0m41.361s
user	0m41.319s
sys	0m0.028s
--8<---------------cut here---------------end--------------->8---

41 s to print hello world, eh.

The problem seems to lie somewhere in the cross-compiled glibc, which
spends lots of time on initializing libpthreads and acquiring mutexes:

--8<---------------cut here---------------start------------->8---
# perf record --call-graph dwarf /path/to/hello_world
# perf report --no-inline
Samples: 12K of event 'cycles', Event count (approx.): 85948101927
  Children      Self  Command  Shared Object       Symbol
+   88.62%     0.00%  hello    libpthread-2.33.so  [.] _init
+   88.62%    11.37%  hello    libpthread-2.33.so  [.] __pthread_initialize_minimal_internal
+   41.84%    34.58%  hello    libpthread-2.33.so  [.] __pthread_mutex_lock_full
+   35.37%    35.18%  hello    libpthread-2.33.so  [.] __pthread_mutex_lock
+   11.19%    11.16%  hello    libpthread-2.33.so  [.] __x86.get_pc_thunk.di
+    7.10%     7.02%  hello    libpthread-2.33.so  [.] __x86.get_pc_thunk.si
     0.59%     0.14%  hello    [kernel.kallsyms]   [k] apic_timer_interrupt
     0.45%     0.00%  hello    [kernel.kallsyms]   [k] smp_apic_timer_interrupt
     0.35%     0.00%  hello    [kernel.kallsyms]   [k] hrtimer_interrupt
     0.28%     0.02%  hello    [kernel.kallsyms]   [k] __hrtimer_run_queues
     0.25%     0.00%  hello    [kernel.kallsyms]   [k] tick_sched_timer
     0.19%     0.00%  hello    [kernel.kallsyms]   [k] tick_sched_handle
     0.19%     0.01%  hello    [kernel.kallsyms]   [k] update_process_times
     0.16%     0.00%  hello    [unknown]           [k] 0xf4a15ff8
     0.13%     0.01%  hello    [kernel.kallsyms]   [k] scheduler_tick
     0.05%     0.01%  hello    [kernel.kallsyms]   [k] irq_exit
     0.05%     0.00%  hello    [kernel.kallsyms]   [k] tick_sched_do_timer
     0.05%     0.00%  hello    [kernel.kallsyms]   [k] tick_do_update_jiffies64.part.12
     0.05%     0.05%  hello    [kernel.kallsyms]   [k] native_write_msr
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] try_to_wake_up
     0.04%     0.04%  hello    [kernel.kallsyms]   [k] restore_all
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] call_on_stack
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] do_softirq_own_stack
     0.04%     0.01%  hello    [kernel.kallsyms]   [k] ktime_get_update_offsets_now
     0.04%     0.01%  hello    [kernel.kallsyms]   [k] perf_event_task_tick
     0.04%     0.01%  hello    [kernel.kallsyms]   [k] perf_pmu_disable.part.92
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] irq_work_interrupt
     0.04%     0.00%  hello    [kernel.kallsyms]   [k] smp_irq_work_interrupt
--8<---------------cut here---------------end--------------->8---

gdb reports:

--8<---------------cut here---------------start------------->8---
(gdb) set auto-load safe-path /
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/user/Desktop/hello
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0xb7f86003 in __GI___pthread_mutex_lock (mutex=0xb7fff584 <_rtld_global+1348>)
    at ../nptl/pthread_mutex_lock.c:71
71  ../nptl/pthread_mutex_lock.c: No such file or directory.
--8<---------------cut here---------------end--------------->8---

Perhaps this problem will resolve with static linking, but I doubt it
given it has to do glibc.

If we could understand/resolve this issue, I'm confident the rest would
mostly be busywork, a couple evenings worth of work at most.

Thank you!

Maxim

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hi again, Ludovic et al!

I'm trying another direction in my reply here based on recent findings;

Ludovic Courtès <ludo@gnu.org> writes:

> 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.

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

Re: Desktops on non-x86_64 systems

[Maxim Cournoyer]

Hello again,

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.

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.

Thanks,

Maxim

Re: Desktops on non-x86_64 systems

[Ludovic Courtès]

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