[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 29 Jul 2016 17:16:29 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Eric Le Bihan <address@hidden> 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?
> 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
Does Rust use GCC, or just ld?
> 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:
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.
> From fb1fbc92cd68331b3dea94c238274f8a01b98afa Mon Sep 17 00:00:00 2001
> From: Eric Le Bihan <address@hidden>
> 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 <address@hidden>
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.
> + ;; 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.
> + (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 \"address@hidden"\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.
> + (replace 'build
> + (lambda* (#:key outputs #:allow-other-keys)
> + (setenv "PATH"
> + (string-append (getcwd) "/bin:" (getenv "PATH")))
> + (mkdir (assoc-ref outputs "out"))
> + (zero? (system* "make")))))
(add-before 'build 'change-PATH
so we can reuse the normal ‘build’ phase, which passes -jX to ‘make’.
> + #:tests? #f))
We normally run test suites, unless we have a good reason not to do so.
:-) Any ideas why “make check” fails?