Re: Rust

[Eric Le Bihan <eric.le.bihan.dev@free.fr>]

Le Fri, 29 Jul 2016 17:16:29 +0200,
ludo@gnu.org (Ludovic Courtès) a écrit :

> Eric Le Bihan <eric.le.bihan.dev@free.fr> skribis:
> 
> > It happens that I tried to package Rust, as an introduction to Guix.
> > Here is my version, inspired by the Haskell package, where Rust
> > 1.10.0 is built, bootstrapped by a binary version of rustc 1.9.0.
> > It uses the "cc" wrapper trick previously presented.  
> 
> As you might have seen from previous discussions, we try hard to
> reduce the number of binary blobs needed to bootstrap packages, such
> that we have a full source-to-binary path that everyone can audit.
> Unfortunately, this usually hard to achieve for self-hosted compilers.
> 
> Do you know what’s Rust’s bootstrapping story is?  Can we reasonably
> expect to bootstrap it from source, using a series of previous Rust
> versions, or using an alternative implementation?

As explained by others, starting with version 1.10.0, Rust version N
will be guaranteed to bootstrap with version N-1.

> > Some questions, though:
> >
> > 1. I can compile a sample program in a guix environment created
> > using `guix environment gcc glibc binutils rust`, but the program
> > generated fails to run because libgcc_s.so.1 can not be found. How
> > can it be added to the environment?  
> 
> As Andreas notes, ‘gcc-toolchain’, which includes ‘ld-wrapper’, should
> fix this.

Yes. It solved my problem.
 
> Does Rust use GCC, or just ld?

It only uses the linker, i.e. ld on GNU/Linux.

> > 2. Having a Rust compiler is cool, but having Cargo, the Rust
> > package manager, would be even better. Cargo is also bootstrapped,
> > and it is also built using zillions of crates (Rust packages)
> > downloaded from the Internet. How could this case be handled in
> > Guix?  
> 
> Assuming Cargo itself is just a regular Rust program, it should be
> possible to make a Guix package of Cargo.  Then, Guix users can
> install it and use it the normal way; we won’t be able to use Cargo
> in package recipes though, because our package build environments
> purposefully lacks network access.
> 
> Besides, I would encourage you or anyone interested to write a crate
> importer, like we do for most other language packages:
> 
>   https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-import.html
> 
> Having crates available as normal Guix packages is the best option for
> Guix users: uniform interface, the ability to use ‘guix environment’
> and all the tools, transactional upgrade and rollback, etc.

IIUC, to provide a Guix package for Cargo, the following should be done:

1. write a crate importer.
2. list all the crates needed by Cargo to build itself.
3. package each crate with the importer.
4. add a Cargo package which depends on the newly-imported crates and
uses a binary version of Cargo to bootstrap itself (though this is not
the best option in terms of auditing/reproducibility).

Unlike Rust, Cargo still uses an "anonymous" binary version of itself
for bootstrapping. I hope this may change soon.

> > From fb1fbc92cd68331b3dea94c238274f8a01b98afa Mon Sep 17 00:00:00
> > 2001 From: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > Date: Thu, 28 Jul 2016 20:09:01 +0200
> > Subject: [PATCH 1/1] gnu: Add rust
> >
> > * gnu/packages/rust.scm(rust): New variable.
> >
> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>  
> 
> Apart from the bootstrapping thing discussed above, this looks good to
> me (and a great first package!).
> 
> > +            ;; Tell where to find libgcc_s.so
> > +            (setenv "LD_LIBRARY_PATH" (string-append gcc-lib
> > "/lib"))  
> 
> “LIBRARY_PATH” may be enough.

OK.
 
> > +            ;; Remove reference to "/lib64/ld-linux-x86-64.so.2"
> > from binary
> > +            (zero? (system*
> > +                    "patchelf"
> > +                    "--set-interpreter" ld-so
> > +                    (string-append (getcwd) "/rustc/bin/rustc")))  
> 
> “rustc/bin/rustc” is enough here.

OK.

> 
> > +        (add-before 'build 'pre-build
> > +                    (lambda _
> > +                      (let* ((bindir (string-append (getcwd)
> > "/bin"))
> > +                             (cc (string-append bindir "/cc")))
> > +                        (mkdir bindir)
> > +                        (call-with-output-file cc
> > +                          (lambda (port)
> > +                            (format port
> > +                                    "#!~a\n\nexec gcc
> > \"$@\"\n" (which "sh"))))
> > +                        (chmod cc #o755))))  
> 
> Can we avoid this trick using a configure flag
> (--with-compiler=/path/to/gcc) or a configure or environment variable
> (CC=gcc)?  If not, that’s fine.

To build the Rust standard library, only the linker is needed. The
default value is "cc". I thought this could be overridden using the
"--default-linker=" of the ./configure script, but it looks like it is
not properly handled. Hence the need for the wrapper. 

I haven't checked too deeply to know if it is a bug or a feature. On
the Rust issue tracker, an entry [1] relates to this problem, but only
in terms of documentation. I'll bump the topic upstream.

> > +      (replace 'build
> > +               (lambda* (#:key outputs #:allow-other-keys)
> > +                 (setenv "PATH"
> > +                         (string-append (getcwd) "/bin:" (getenv
> > "PATH")))
> > +                 (mkdir (assoc-ref outputs "out"))
> > +                 (zero? (system* "make")))))  
> 
> Rather do:
> 
>   (add-before 'build 'change-PATH
>     (lambda _
>       (setenv …)
>       #t))
> 
> so we can reuse the normal ‘build’ phase, which passes -jX to ‘make’.

OK.

> 
> > +      #:tests? #f))  
> 
> We normally run test suites, unless we have a good reason not to do
> so. :-)  Any ideas why “make check” fails?

Out of laziness, I skipped the tests. I'll give it a look.

[1] https://github.com/rust-lang/rust/issues/32208

Best regards,

-- 
ELB