guix-devel
[Top][All Lists]
Advanced

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

Re: bootstrap: i686-linux now builds without binutils, gcc seeds


From: Ricardo Wurmus
Subject: Re: bootstrap: i686-linux now builds without binutils, gcc seeds
Date: Mon, 17 Sep 2018 23:55:02 +0200
User-agent: mu4e 1.0; emacs 26.1

Hi janneke!

> I have added this text to wip-bootstrap, image not shown inline here,
> WDYT?
[…]
> address@hidden Reduced Binary Seed Bootstrap
> address@hidden The Reduced Binary Seed Bootstrap
> +
> +Guix---like other GNU/Linux distributions---is traditionally bootstrapped 
> from
> +from a set of bootstrap binaries: Bourne shell, command-line tools provided 
> by

    ^— this is an extra “from”.

> +GNU Coreutils, Awk, Findutils, `sed', and `grep' and Guile, GCC, Binutils, 
> and
> +the GNU C Library (@pxref{Bootstrapping}).  Usually, these bootstrap-binaries

“bootstrap binaries”

> +are ``taken for granted.''
> +
> +What does this mean, really?  By taking these binaries for granted, trusting
> +Guix depends on the trusting these binaries to be correct and clean.  Therein

How about this instead of the second sentence:

“Taking these binaries for granted means that we consider them to be a
correct and trustworthy ‘seed’ for building the complete system.”

> +lies a problem: the current combined size of these bootstrap-binaries is 
> about

“bootstrap binaries”

> +250MB (@pxref{Bootstrappable Builds,,, mes, Mes Reference Manual}).  Auditing
> +or even inspecting these is next to impossible.
> +
> +For @code{i686-linux}, Guix now features a ``Reduced Binary Seed'' bootstrap
> address@hidden would like to say: ``Full Source Bootstrap'' and while we are
> +working towards that it would be a hyperbole to use that term for what we do
> +now.}.

“would be hyperbole” (no “a”)

> +The Reduced Binary Seed bootstrap removes the most critical tools---from a
> +trust perspective---from the bootstrap binaries: GCC, Binutils and the GNU C
> +Library are replaced by: @code{mescc-tools-seed} (a tiny assembler and 
> linker)
> address@hidden (a small Scheme Interpreter and a C compiler writen in Scheme)
> +and @code{tinycc-seed} (the Mes C Library, built for TinyCC).  Using these 
> new
> +binary seeds and a new set of
> address@hidden
> +package address@hidden@c

I’d remove “descriptions”.

> +mescc-tools-boot,
> +nyacc-boot,
> +mes-boot,
> +tcc-boot0,
> +tcc-boot,
> +make-mesboot0,
> +diffutils-mesboot,
> +binutils-mesboot0,
> +gcc-core-mesboot,
> +mesboot-headers,
> +glibc-mesboot0,
> +gcc-mesboot0,
> +binutils-mesboot,
> +make-mesboot,
> +gcc-mesboot1,
> +gcc-mesboot1-wrapper,
> +glibc-headers-mesboot,
> +glibc-mesboot,
> +gcc-mesboot,

+ “and”

> +gcc-mesboot-wrapper.
> +}
> address@hidden
> +the ``missing'' Binutils, and the GNU C Library are built, from source.  From

“, from source” –> “ from source”.

> +here on the more traditional bootstrap process resumes.  This approach has
> +reduced the bootstrap binaries in size to about 130MB.  Work is ongoing to
> +reduce this further.  If you are interested, join us on @code{#boottrappable}

typo: #bootstrappable

> +on the Freenode IRC network.
> +
> address@hidden ./pre-inst-env guix graph --type=bag -e '(begin (use-modules 
> (guix packages)) (%current-system "i686-linux") (@@ (gnu packages 
> commencement) gcc-mesboot))' > doc/images/gcc-mesboot-bag-graph.dot
> address@hidden dot -T png doc/images/gcc-mesboot-bag-graph.dot > 
> doc/images/gcc-mesboot-bag-graph.png
> +
> +Below is the generated dependency graph to for @code{gcc-mesboot} that builds
> +the rest of GuixSD.

“to for” –> “for”

How about this:

  Below is the generated dependency graph for @code{gcc-mesboot}, the
  bootstrap compiler used to build the rest of GuixSD.

>>   • I think all the “mesboot” & co. packages in commencement.scam can be
>>     made private–i.e., changing ‘define-public’ to ‘define’.
>
> I agree; I kept gcc-mesboot (the final gcc) public, is that OK?

If it isn’t referenced by other modules and would not be installed by
users I think it doesn’t need to be public, but I think either way is
fine.

Thanks!

--
Ricardo




reply via email to

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