all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Cc: guix-devel@gnu.org
Subject: Rust
Date: Fri, 29 Jul 2016 17:16:29 +0200	[thread overview]
Message-ID: <87mvl0a302.fsf_-_@gnu.org> (raw)
In-Reply-To: <20160728203144.7df4bb8c@itchy> (Eric Le Bihan's message of "Thu, 28 Jul 2016 20:31:44 +0200")

Hello,

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?

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

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:

  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.

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

> +            ;; 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 \"$@\"\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")))))

Rather do:

  (add-before 'build 'change-PATH
    (lambda _
      (setenv …)
      #t))

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?

Thanks!

Ludo’.

  parent reply	other threads:[~2016-07-29 15:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-25 17:45 LLVM: "FileCheck" is missing Danny Milosavljevic
2016-03-25 21:58 ` Nils Gillmann
2016-03-25 22:06 ` rust work in progress conflicts (was: Re: LLVM: "FileCheck" is missing) Nils Gillmann
2016-05-04 10:34   ` Jelle Licht
2016-05-05 13:35     ` rust work in progress conflicts Ludovic Courtès
2016-05-05 14:46       ` Alex Griffin
2016-05-06  9:05         ` Andy Wingo
2016-05-06  9:15           ` Andy Wingo
2016-05-06  9:59         ` Ludovic Courtès
2016-05-05 15:06     ` ng0
2016-07-28  8:28       ` ng0
2016-07-28 18:31         ` Eric Le Bihan
2016-07-29  9:03           ` Andreas Enge
2016-07-29 11:40             ` Vincent Legoll
2016-07-29 14:37               ` ng0
2016-07-30 10:04             ` Eric Le Bihan
2016-07-29 15:16           ` Ludovic Courtès [this message]
2016-07-29 15:34             ` Rust Alex Griffin
2016-07-29 16:08               ` Rust Jelle Licht
2016-07-30 13:34               ` Rust Ludovic Courtès
2016-07-30 17:57                 ` Rust Pjotr Prins
2016-07-30 11:01             ` Rust Eric Le Bihan
2016-07-30 13:44               ` Rust Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2016-07-29 19:10 Rust David Craven
2016-07-30 13:39 ` Rust Ludovic Courtès
2016-09-04 14:50 Rust David Craven
2016-09-07  6:04 ` Rust Eric Le Bihan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvl0a302.fsf_-_@gnu.org \
    --to=ludo@gnu.org \
    --cc=eric.le.bihan.dev@free.fr \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.