Le Fri, 29 Jul 2016 17:16:29 +0200, l...@gnu.org (Ludovic Courtès) a écrit :
> Eric Le Bihan <eric.le.bihan....@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....@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....@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
