From mboxrd@z Thu Jan 1 00:00:00 1970 From: janneke Subject: Re: bootstrap: i686-linux progress report Date: Sun, 09 Sep 2018 19:34:29 +0200 Message-ID: <87h8iya82i.fsf@gnu.org> References: <87ftykgiej.fsf@gnu.org> 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]:36722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fz3f5-0005qO-BE for guix-devel@gnu.org; Sun, 09 Sep 2018 13:38:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fz3bY-00052U-By for guix-devel@gnu.org; Sun, 09 Sep 2018 13:34:37 -0400 In-Reply-To: <87ftykgiej.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Sat, 08 Sep 2018 16:42:28 +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: guix-devel@gnu.org 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=3Di686-linux hello > > on x86_64 (Previously, I did most development in a x86 VM which hides > problems with --system=3D setting) and I verified that > > ./pre-inst-env guix graph --type=3Dbag -e '(begin (use-modules (guix = packages) (gnu packages base)) (%current-system "i686-linux") hello)' > > does not include any `glibc-bootstrap', `gcc-bootstrap' or `binutils-boot= strap'. > > 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 directo= ry > > > > Building bison-boot0, I removed the added `-D' flag to ranlib > > bison-boot0: > > #:make-flags `("ARFLAGS=3DcrD" > ,,(match (%current-system) > ;; ranlib: '-D': No such file > ("i686-linux" "RANLIB=3Dranlib") > (_ "RANLIB=3Dranlib -D")) > "V=3D1")))))) > > > 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-boot= strap-binaries-0/bin/install -c .libs/libstdc++.so.6.0.20 /gnu/store/np5pmd= lwfin3vmqk88chh0fgs0ncki79-libstdc++-boot0-4.8.5/lib/libstdc++.so.6.0.20 > ;; /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-binaries-0/b= in/install: cannot stat '.libs/libstdc++.so.6.0.20': No such file or direct= ory > (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/7swwdnq02lqk4xkd8740fxdj1h4va= 38l-bootstrap-binaries-0/bin/install -c .libs/libcc1.so.0.0.0 /gnu/store/8q= f47i99nxz9jvrmq5va0g3q1yvs3x74-gcc-cross-boot0-5.5.0-lib/lib/./libcc1.so.0.= 0.0 > ;; /gnu/store/7swwdnq02lqk4xkd8740fxdj1h4va38l-bootstrap-bina= ries-0/bin/install: cannot stat '.libs/libcc1.so.0.0.0': No such file or di= rectory > (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 hand= ful 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 o= n a > richer libc. while grafting the guix bootstrap onto this mes triple= t, 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? > --=20 Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar=C2=AE http://AvatarAcademy.com