From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Rust Date: Fri, 29 Jul 2016 17:16:29 +0200 Message-ID: <87mvl0a302.fsf_-_@gnu.org> References: <20160325184540.4e02cb2d@scratchpost.org> <87k2kq6wma.fsf@grrlz.net> <87oa8mt8lh.fsf@gmail.com> <87eg9gzgqb.fsf@libertad.pw> <87popyp3od.fsf@we.make.ritual.n0.is> <20160728203144.7df4bb8c@itchy> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bT9Wh-0003LF-PW for guix-devel@gnu.org; Fri, 29 Jul 2016 11:16:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bT9Wb-0006CH-PR for guix-devel@gnu.org; Fri, 29 Jul 2016 11:16:38 -0400 In-Reply-To: <20160728203144.7df4bb8c@itchy> (Eric Le Bihan's message of "Thu, 28 Jul 2016 20:31:44 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Eric Le Bihan Cc: guix-devel@gnu.org Hello, Eric Le Bihan 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=E2=80=99s Rust=E2=80=99s bootstrapping story is? Can we r= easonably 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, =E2=80=98gcc-toolchain=E2=80=99, which includes =E2=80=98= ld-wrapper=E2=80=99, should fix this. 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=E2=80=99t be able to use Cargo in pack= age 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.h= tml Having crates available as normal Guix packages is the best option for Guix users: uniform interface, the ability to use =E2=80=98guix environment= =E2=80=99 and all the tools, transactional upgrade and rollback, etc. > From fb1fbc92cd68331b3dea94c238274f8a01b98afa Mon Sep 17 00:00:00 2001 > From: Eric Le Bihan > 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 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")) =E2=80=9CLIBRARY_PATH=E2=80=9D may be enough. > + ;; Remove reference to "/lib64/ld-linux-x86-64.so.2" from bi= nary > + (zero? (system* > + "patchelf" > + "--set-interpreter" ld-so > + (string-append (getcwd) "/rustc/bin/rustc"))) =E2=80=9Crustc/bin/rustc=E2=80=9D 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 \"$@\"\n" (which "= sh")))) > + (chmod cc #o755)))) Can we avoid this trick using a configure flag (--with-compiler=3D/path/to/gcc) or a configure or environment variable (CC=3Dgcc)? If not, that=E2=80=99s 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"))))) Rather do: (add-before 'build 'change-PATH (lambda _ (setenv =E2=80=A6) #t)) so we can reuse the normal =E2=80=98build=E2=80=99 phase, which passes -jX = to =E2=80=98make=E2=80=99. > + #:tests? #f)) We normally run test suites, unless we have a good reason not to do so. :-) Any ideas why =E2=80=9Cmake check=E2=80=9D fails? Thanks! Ludo=E2=80=99.