From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2ACD11F44D for ; Mon, 22 Apr 2024 10:07:18 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Nk4XFmd6; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryqZX-00010g-KS; Mon, 22 Apr 2024 06:06:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ryqZU-00010A-UF for bug-gnulib@gnu.org; Mon, 22 Apr 2024 06:06:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ryqZR-0008Lx-Hw; Mon, 22 Apr 2024 06:06:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=GW8GkbYEcq2Ghue5EMHKuWBaFkwKEvOtWUA2LIhyZ4c=; b=Nk4XFmd6lk5FCrdv9Rcv yH7qK8yevFYZ1NpRHNHs12rHKO6oQhVbZXpkozLShVP1UxnoIYQeCBV/9X4fdcJsYhAFbnX6b4BCn BiRGUyo586vKnoetwF2BhZ5S99wIk1b2EVnYZm8ThdaQDuxC7prVIPVpct8boYWv3EhwTWKpoOKoW 90mSZEdt6phT7ub0Ez0cYiFtstVlC9njrxE72YqqhRF3W/tuHWKiQxVkbXq2TIRZGF2Ot9+t2KjeM LM3Vzpq2uLAa28Y9u9AACy7U/2ezdztX9VeOdKebcSdrGwUwt7oB/gx8Lyq0hC9VyFkoTTKlCZJqw EmOn8QCgq5s0Gg==; From: Janneke Nieuwenhuizen To: Bruno Haible Cc: Bernhard Voelker , bug-gnulib@gnu.org, Paul Eggert Subject: Re: full-source bootstrap and Python In-Reply-To: <6072062.karAmqqFpX@nimes> (Bruno Haible's message of "Sun, 21 Apr 2024 18:07:37 +0200") Organization: AvatarAcademy.nl References: <17575364.8ZXASUQcjA@nimes> <0d69dedd-f4d6-4ca1-9c1c-c127656fc37b@bernhard-voelker.de> <87mspmbvc5.fsf@gnu.org> <6072062.karAmqqFpX@nimes> X-Url: http://AvatarAcademy.nl Date: Mon, 22 Apr 2024 12:06:41 +0200 Message-ID: <87le55k8y6.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Bruno Haible writes: Hi! > Janneke Nieuwenhuizen wrote: >> Are are we creating a problem for >> bootstrapping (or even a dependency cycle) when introducing this new >> dependency into a certain package. > > I think you answered this question with "no", when writing in [1]: > > "Even more recently (2018), the GNU C Library glibc-2.28 adds Python > as a build requirement" How so? In 2013, the GCC folks decided that their gcc-4.8 would no longer be a directly bootstrappable compiler by introducing a (casual?) dependency on c++. That's pretty bad for bootstrapping, and it would be amazing if someone could revet that mistake. With glibc-2.28, a similar bootstrappable mistake was made. Making an essential GNU package such as GCC or Glibc non-bootstrappable has severe consequences. As an example, we have been working on the RISC-V bootstrap for about a year with three people. One of the problems here is that RISC-V was only added to a non-bootstrappable version of GCC: 7.5.0, while the GCC team failed to maintain their last bootstrappable version: 4.7.4. In other words, the RISC-V backend needed to backported and someone else now needs to maintain a bootstrappable version of GCC. When something else like this changes in the future, that isn't as "easily" backported, what do we do? Terrible! > So, how do you avoid Python when building glibc? Do you use musl libc as > a first stage, and only build glibc once a python built with musl exists? Currently we aren't directly hit by this because we build glibc-2.2.5 and glibc-2.16 first. We added these earlier Glibc's because we allowed ourcelves to cut some corners and there earlier versions were more easy to bootstrap. On the roadmap is to remove as many ancient versions as we can, as they are potential time-bombs. In fact, glibc-2.2.5 is problematic for the ARM and the RISC-V bootstrap, so we'll get rid of that. We won't be able to get rid of advancing beyond glibc-2.27 without adding a yet another non-GNU package such as musl libc. Possibly a nice hack for now, but what to do when we want to port the bootstrap to the Hurd? Again, terrible! > Also, from the diagrams in [1][2][3] it looks like the full-source bootst= rap > uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So, > even if newer versions of 'make' or 'gcc' will use a Python-based gnulib-= tool, > there won't be a problem, because the bootstrap of these old tarballs will > be unaffected. indeed. For the current situtation (that's less than great and are working on to resolve), making essential GNU packages less bootstrappable is of no consequence. Cleaning-up the full-source bootstrap and making it more or less future-proof, might be challenged by such a new dependency. Greetings, Janneke --=20 Janneke Nieuwenhuizen | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar=C2=AE https://AvatarAcade= my.com