From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jookia <166291@gmail.com> Subject: Re: Removing compilers that cannot be bootstrapped Date: Tue, 22 Mar 2016 20:56:28 +1100 Message-ID: <20160322095628.GA13538@novena-choice-citizen.lan> References: <87twjz4fcn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1aiJ5s-0005mT-Qp for guix-devel@gnu.org; Tue, 22 Mar 2016 05:59:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <166291@gmail.com>) id 1aiJ5r-0006mb-Lr for guix-devel@gnu.org; Tue, 22 Mar 2016 05:59:20 -0400 Content-Disposition: inline In-Reply-To: <87twjz4fcn.fsf@gnu.org> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: guix-devel On Mon, Mar 21, 2016 at 11:48:40PM +0100, Ludovic Courtès wrote: > Often, in their implementation history, compilers are boostrapped from > something else initially, and only later to they become self-hosted and > unbootstrappable. > > So in theory, it’d be possible to find, say, an old-enough GHC that only > requires a C compiler (?), and use that to build the next version and so > on, until we reach the latest version. I suspect the same applies to > many compilers. I'm not sure about this. Bootstrapping older compilers means there's often less support for the platform you're on, which means we'll end up in a situation where we're bootstrapping from machines and cross-compiling, and I forsee the problem being that we'll have to rely on nonfree code or machines as our huge backhaul in a decade where we're on some cool free hardware RISC architecture. For instance, to run GHC on ARM you can only use a recent GHC, all the old versions didn't support it. Sure you could go from C to get an old GHC on ARM, but it wouldn't have support for outputting ARM assembly. > This is technically possible. The main difficulty is to find what exact > chain of compiler versions will work, and then to make sure that the > super-old compilers can build. The risk, as Andreas suggests, is that > maintaining those old versions will require dragging a whole graph of > old dependencies, recursively. Guix could be well suited to this with its ability to create environments with bitrotted tools. > But really, we won’t know until we’ve actually tried ;-), and it’ll > be different for each compiler. > > I would suggest that people pick a compiler they’re more or less > familiar with, and give it a try. MIT/GNU Scheme might be a good start, > since we should be able to talk with the folks behind it and reach > mutual understanding. ;-) > > For GCC, an idea discussed at > would > be to build GCC 4.7 (the last version written in plain C) with something > more auditable like TinyCC, and then use this g++ 4.7 to build whatever > GCC version we want. Again, sounds like it should work, but we need to > actually try. Sounds interesting, and even better if we could compile the rest of the bootstrap with just TinyCC. > Thoughts? Many! :) > BTW, the “good news” is that more and more compilers build upon LLVM, > and for those there’s no bootstrapping problem if we take the C++ > compiler for granted. Is this true? I know a lot of compilers *use* LLVM as a backend, but not sure about their frontends. That said, LLVM's a bit of a problem in itself, to the point GHC has decided to fix a lot of their issues with the ARM platform by bundling a LLVM version to be consistent across distros. I think there's also been talk of taking advantage of this to remove useless phases or add Haskell-specific ones to LLVM, so we'd end up LLVM just being another part of the toolchain. This is a bit off topic though since it doesn't relate to bootstrapping but to bundling. ;) > Ludo’. Jookia.