bootstrap: i686-linux progress report

bootstrap: i686-linux progress report

[Jan Nieuwenhuizen]

For the 3rd time, again I believe that I have built i686-linux `hello'
without using any bootstrap inputs.  This time, I have actually built

    ./pre-inst-env guix build --system=i686-linux hello

on x86_64 (Previously, I did most development in a x86 VM which hides
problems with --system= setting) and I verified that

    ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages) (gnu packages base)) (%current-system "i686-linux") hello)'

does not include any `glibc-bootstrap', `gcc-bootstrap' or `binutils-bootstrap'.

I found that using package-with-explicit-inputs often still sometimes
has these packages leak in.  I didn't manage to find out how or why.

Using :implicit-inputs #f and #:guile %bootstrap-guile produces a clean
package.  So I rewrote

    diffutils-boot0
    findutils-boot0
    file-boot0
    perl-boot0
    m4-boot0
    bison-boot0

to use that instead.

Maybe we want to look at package-with-explicit-inputs and change/fix it?

Also, i worked on glibc-2.16.0 to *really* remove all shreads of sunrpc.
That was more work than expected but finally that fixed building
gettext-boot0

--8<---------------cut here---------------start------------->8---
gettext-boot0: netdb.h: fatal error: rpc/netdb.h: No such file or directory
--8<---------------cut here---------------end--------------->8---


Building bison-boot0, I removed the added `-D' flag to ranlib

bison-boot0:
--8<---------------cut here---------------start------------->8---
    #:make-flags `("ARFLAGS=crD"
                   ,,(match (%current-system)
                       ;; ranlib: '-D': No such file
                       ("i686-linux" "RANLIB=ranlib")
                       (_ "RANLIB=ranlib -D"))
                   "V=1"))))))
--8<---------------cut here---------------end--------------->8---

AFAICS, bootstrap-cross-boot0 does not support the -D flag.  How did
this ever work -- did binutils-bootstrap-0 always leak-in here?

Next, I made two very ugly hacks to build libstdc++-boot0 and gcc-boot0

libstdc++-boot0:
--8<---------------cut here---------------start------------->8---
    ;; FIXME: why doesn't this package build libstdc++.so.6.0.20,
    ;; when gcc-mesboot builds it fine?
    ;; libtool: install: /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install -c .libs/libstdc++.so.6.0.20 /gnu/store/np5pmdlwfin3vmqk88chh0fgs0ncki79-libstdc++-boot0-4.8.5/lib/libstdc++.so.6.0.20
    ;; /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install: cannot stat '.libs/libstdc++.so.6.0.20': No such file or directory
    (add-after 'build 'copy-libstdc++-
      (lambda* (#:key outputs #:allow-other-keys)
        (let ((gcc (assoc-ref %build-inputs "gcc"))
              (out (assoc-ref outputs "out")))
          (copy-file (string-append gcc "/lib/libstdc++.so.6.0.20")
                     (string-append "src/.libs/libstdc++.so.6.0.20"))
          #t)))))))
--8<---------------cut here---------------end--------------->8---


gcc-boot0:
--8<---------------cut here---------------start------------->8---
    ,(match (%current-system)
       ("i686-linux"
        '(add-after 'build 'libtool-workaround
          (lambda _
            ;; libtool: install: /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install -c .libs/libcc1.so.0.0.0 /gnu/store/8qf47i99nxz9jvrmq5va0g3q1yvs3x74-gcc-cross-boot0-5.5.0-lib/lib/./libcc1.so.0.0.0
            ;; /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install: cannot stat '.libs/libcc1.so.0.0.0': No such file or directory
            (system* "touch"
                     "libcc1/.libs/libcc1.so.0.0.0"
                     "libcc1/.libs/libcc1plugin.so.0.0.0"))))
       (_ 'identity))
--8<---------------cut here---------------end--------------->8---

Updated the wip-bootstrap branch @ savannah.

I'm now working on a patch for Mes to allow upgrading Nyacc to 0.86.0
which will of course trigger a full rebuild.

TODO:
    * have someone reproduce these results
    * review the wip-bootstrap branch
    * understand the need for the hacks I introduced, clean them up
    * check wip-bootstrap doesn't break other architectures/cross build, ...
    * verify that wip-bootstrap builds reproducible (ranlib -D?)
    * merge it, or squash the 207 commits into a single or at most a handful of commits?
    * refactor the full source bootstrap*)
    * other architectures
    * gash/geesh
    * ...?

janneke

*) - the initial gnu triplet is currently binutils-2.20, glibc-2.2.5 and gcc-2.95.3.
     one reason for choosing this triplet is that newer versions depend on a
     richer libc.  while grafting the guix bootstrap onto this mes triplet, the
     Mes C Library was enriched; so possibly we could target a newer
     triplet: gcc-3.x, or maybe we want to enrich Mes C Library further.
   - gcc-mesboot-4.9.4 was inserted between gcc-mesboot1-4.7.4, it would
     be nice if one of those could be removed.
   - gcc-mesboot-4.9.4 is compiled with --enable-shared; that may be
     cause of the ugly libstdc++/gcc-boot0 libtool hacks?  OTOH, it
     provides the libstdc++.so.6.0.20 that we need in libstdc++-boot0?

Re: bootstrap: i686-linux progress report

[janneke]

Jan Nieuwenhuizen writes:

All the info below is still valid, just to give you a heads-up that I
squashed the wip-bootstrap branch from 209 down to 14 commits.  The 2
last introduce the mes bootstrap, the 12 others are preparations.

janneke

> For the 3rd time, again I believe that I have built i686-linux `hello'
> without using any bootstrap inputs.  This time, I have actually built
>
>     ./pre-inst-env guix build --system=i686-linux hello
>
> on x86_64 (Previously, I did most development in a x86 VM which hides
> problems with --system= setting) and I verified that
>
>     ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages) (gnu packages base)) (%current-system "i686-linux") hello)'
>
> does not include any `glibc-bootstrap', `gcc-bootstrap' or `binutils-bootstrap'.
>
> I found that using package-with-explicit-inputs often still sometimes
> has these packages leak in.  I didn't manage to find out how or why.
>
> Using :implicit-inputs #f and #:guile %bootstrap-guile produces a clean
> package.  So I rewrote
>
>     diffutils-boot0
>     findutils-boot0
>     file-boot0
>     perl-boot0
>     m4-boot0
>     bison-boot0
>
> to use that instead.
>
> Maybe we want to look at package-with-explicit-inputs and change/fix it?
>
> Also, i worked on glibc-2.16.0 to *really* remove all shreads of sunrpc.
> That was more work than expected but finally that fixed building
> gettext-boot0
>
> gettext-boot0: netdb.h: fatal error: rpc/netdb.h: No such file or directory
>
>
>
> Building bison-boot0, I removed the added `-D' flag to ranlib
>
> bison-boot0:
>
>     #:make-flags `("ARFLAGS=crD"
>                    ,,(match (%current-system)
>                        ;; ranlib: '-D': No such file
>                        ("i686-linux" "RANLIB=ranlib")
>                        (_ "RANLIB=ranlib -D"))
>                    "V=1"))))))
>
>
> AFAICS, bootstrap-cross-boot0 does not support the -D flag.  How did
> this ever work -- did binutils-bootstrap-0 always leak-in here?
>
> Next, I made two very ugly hacks to build libstdc++-boot0 and gcc-boot0
>
> libstdc++-boot0:
>
>     ;; FIXME: why doesn't this package build libstdc++.so.6.0.20,
>     ;; when gcc-mesboot builds it fine?
>     ;; libtool: install: /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install -c .libs/libstdc++.so.6.0.20 /gnu/store/np5pmdlwfin3vmqk88chh0fgs0ncki79-libstdc++-boot0-4.8.5/lib/libstdc++.so.6.0.20
>     ;; /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install: cannot stat '.libs/libstdc++.so.6.0.20': No such file or directory
>     (add-after 'build 'copy-libstdc++-
>       (lambda* (#:key outputs #:allow-other-keys)
>         (let ((gcc (assoc-ref %build-inputs "gcc"))
>               (out (assoc-ref outputs "out")))
>           (copy-file (string-append gcc "/lib/libstdc++.so.6.0.20")
>                      (string-append "src/.libs/libstdc++.so.6.0.20"))
>           #t)))))))
>
>
>
> gcc-boot0:
>
>     ,(match (%current-system)
>        ("i686-linux"
>         '(add-after 'build 'libtool-workaround
>           (lambda _
>             ;; libtool: install: /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install -c .libs/libcc1.so.0.0.0 /gnu/store/8qf47i99nxz9jvrmq5va0g3q1yvs3x74-gcc-cross-boot0-5.5.0-lib/lib/./libcc1.so.0.0.0
>             ;; /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/bin/install: cannot stat '.libs/libcc1.so.0.0.0': No such file or directory
>             (system* "touch"
>                      "libcc1/.libs/libcc1.so.0.0.0"
>                      "libcc1/.libs/libcc1plugin.so.0.0.0"))))
>        (_ 'identity))
>
> Updated the wip-bootstrap branch @ savannah.
>
> I'm now working on a patch for Mes to allow upgrading Nyacc to 0.86.0
> which will of course trigger a full rebuild.
>
> TODO:
>     * have someone reproduce these results
>     * review the wip-bootstrap branch
>     * understand the need for the hacks I introduced, clean them up
>     * check wip-bootstrap doesn't break other architectures/cross build, ...
>     * verify that wip-bootstrap builds reproducible (ranlib -D?)
>     * merge it, or squash the 207 commits into a single or at most a handful of commits?
>     * refactor the full source bootstrap*)
>     * other architectures
>     * gash/geesh
>     * ...?
>
> janneke
>
> *) - the initial gnu triplet is currently binutils-2.20, glibc-2.2.5 and gcc-2.95.3.
>      one reason for choosing this triplet is that newer versions depend on a
>      richer libc.  while grafting the guix bootstrap onto this mes triplet, the
>      Mes C Library was enriched; so possibly we could target a newer
>      triplet: gcc-3.x, or maybe we want to enrich Mes C Library further.
>    - gcc-mesboot-4.9.4 was inserted between gcc-mesboot1-4.7.4, it would
>      be nice if one of those could be removed.
>    - gcc-mesboot-4.9.4 is compiled with --enable-shared; that may be
>      cause of the ugly libstdc++/gcc-boot0 libtool hacks?  OTOH, it
>      provides the libstdc++.so.6.0.20 that we need in libstdc++-boot0?
>

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com