guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rust work in progress conflicts


From: Ludovic Courtès
Subject: Re: rust work in progress conflicts
Date: Thu, 05 May 2016 15:35:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Jelle Licht <address@hidden> skribis:

> Now there are two approaches which might make sense to me:
>
> 1) We package a recent stage-0 binary (thus adding yet another random
> binary to the mix)

This is something we want to avoid as much as possible.  Part of the
solution is to raise awareness about the security and freedom issues
that arise from the use of binary blobs to build compilers.

This has been discussed earlier:

  https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00828.html

Based on this discussion…

> 2) We bootstrap all the way from the original rust compiler, written in
> ocaml. This would then presumably need to be repeated for each snapshot,
> leading to about 319 iterative compiler build. On my kind-of-okay i7,
> compiling a single rust iteration takes about 25 to 40 minutes.

… I strongly encourage you to try and take this route.

Hopefully, not every version of Rust needs to be compiled with exactly
the previous version of itself.

Anyway, your experience in trying this will be invaluable!

> I tentatively went with option 1, if only because I would like to see
> results this decade still, and ran into several hurdles that became
> quite manageable with help from the good people of #guix and
> #rust-internals. One more issue yet remains: part of the rust
> compilation process actually calls the 'cc linker'. This part does not
> respect make flags, setenv calls or even rust's special configure flag
> for setting cc.

At worst, you can always add a ‘cc’ script that does:

  #!$SHELL
  exec gcc "$@"

in $PATH, in a pre-build phase.

> Option 1 does not seem feasible at this point of time, but there is some
> light at the end of the tunnel: rust is at some point going to follow a
> convention that will allow bootstrapping compilers via 'master from
> beta, beta from stable and stable from previous stable'[2].
>
> I am currently thinking of a compromise; basically, at this moment go
> for option 1, and once the policy previously described is properly
> implemented by the rust team, start iteratively bootstrapping rust from
> that point in time.

Yeah it’s OK to do it in the order: write the package bootstrapped from
the binary blob, and then work on bootstrapping it from OCaml.

Thanks for looking into it!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]