Re: A different way to bootstrap and build GCC

[Ekaitz Zarraga <ekaitz@elenq.tech>]

Hi!

On 2024-11-24 00:20, Stefan wrote:
> Hi!
> 
> I got a step further with the different way to build GCC.  The problem 
> not using the proper multilib variant for embedded systems is solved now 
> and I updated to GCC 14.2.
> 
> To cite myself, my gut feeling is that the whole GCC version chain 
> starting in (gnu packages commencement) should be build this way.  So I 
> started to play around with the bootstrapping of GCC.
> 
> Starting with only few packages from (gnu packages commencement) I so 
> far managed to build a static GCC 10.4.0 using a static musl 1.2.5.
> 
> The initial packages I reuse are:
> 
> %bootstrap-guile
> gash-boot
> bootar
> gash-utils-boot
> tcc-boot0
> gnu-make-mesboot0
> gmp-boot
> mpfr-boot
> mpc-boot
> 
> 
> Using only these I build a recent TCC from 2024-08-20 with Mes from 
> tcc-boot0 as C library, and then MUSL 1.2.5. Then (only) three 
> iterations of TCC with musl are needed to get a stable TCC with working 
> floating point support.
> 
> The chain continues with GNU Make 4.4.1, Binutils 2.42, Findutils 
> 4.10.0, GCC 4.6.4 with gmp-boot, mpfr-boot, mpc-boot (the version with 
> the RISC-V patches may just work), M4 1.4.19, GMP 6.3.0, MPFR 4.2.1, MPC 
> 1.3.1, GCC 10.4.0.
> 
> These are all static builds so far.  I'm using latest versions of all 
> packages, except Binutils, whose version 2.43 does not link the object 
> files from TCC.  I avoid to use --build=i686-unknown-linux-gnu to make 
> it possible to build for other architectures as well.
> 
> I think the next step should be GCC 14, then glibc with shared library 
> support and GCC 14 again.
> 
> I need several small patches to work around shortcomings in Mes, gash, 
> gash-utils, missing functionality of version 3.8.0 of gnu-make-mesboot0 
> (version 3.81 would have it), bugs in TCC.  They are all described in 
> the comments.  Maybe gash and gash-utils could be improved in future.  
> The most annoying thing is that only one core can be used for the 
> builds, otherwise they hang.  I guess it is related to gash in 
> combination with %bootstrap-guile, at least using Make 4.4.1 makes no 
> difference.
> 
> I published a git repository at 
> <https://git.pub.solar/stefan/embedded-channel>.  Unfortunately it's not 
> a proper channel yet.  If someone likes to give that bootstrap path a 
> try, use this command:
> 
> guix build --cores=1 -L <your-checkout-here> GCC-10-bootstrap
> 
> The working GCCs can be build with
> 
> guix build -L <your-checkout-here> GCC GCC-cross-picolibc-arm-none-eabi, 
> GCC-cross-newlib-arm-none-eabi
> 
> There are GCC…-toolchain package as well, which propagate ld and all the 
> other tools from Binutils.  But if these tools are only used indirectly 
> through the gcc or g++ drivers, these GCC…-toolchain packages are not 
> needed at all, as the GCC packages are standalone.  There are also 
> GCC…-c-toolchain variables for use with package-with-c-toolchain.  There 
> is no separate libstdc++ package yet, the library is just part of GCC.  
> A separate package will only be needed for Clang or other compilers 
> (maybe Zig), but I'm not sure yet, if clang actually needs a dependency 
> to GCC.
> 
> I hope this will be useful, maybe it can help the RISC-V bootstrap 
> effort.  I'm open for suggestions how to proceed from here.
> 
> 
> Bye
> 
> Stefan


Very interesting work. I'll read it with more detail tomorrow but at the 
moment it feels very similar to what we did for RISC-V (which is more or 
less what live-bootstrap does):

https://github.com/ekaitz-zarraga/commencement.scm

Is there any obvious difference in the beginning of the chain that I'm 
missing?

We also agreed in the RISC-V port that using musl makes everything 
easier, mostly because of the RISC-V support is a complicated in 
glibc+gcc couples, but also because Musl is very easy to compile (and 
also read and patch, when needed).

We also went straight for a modern GCC and left many other packages in 
the way.

Efraim is working adapt that into Guix so he probably would have more to 
say about it.

Interesting work, thanks for sharing!

Ekaitz