Toolchain bootstrapping advice needed

[Bryan Ischo]

On 08/09/11 04:34, David Hagood wrote:
> On Tue, 2011-08-09 at 01:43 -0700, Bryan Ischo wrote:
>> I've recently embarked upon a possibly futile effort to create a script
>> to bootstrap a GNU toolchain - binutils, gcc, and glibc - from a system
>> with the most minimal of prerequisites.
> So am I!

Very good - hopefully together we can figure this out ...

> Cue the "just use crosstools" comments. Crosstools purports to do
> exactly that. I've found it doesn't fit my needs, but maybe it will fit
> yours. I want to do what you are doing, but going one step further:
> capturing all the toolchain requirements in a form that will let me
> regenerate it ten years later without external servers (which is hard
> with crosstools).
Yes, I did investigate the tool, and it did prove a valuable place to 
look for some patches that fixed some problems that I was encountering, 
but it didn't work for me out-of-the-box.  It has alot of bells and 
whistles that are extraneous to my requirements and with something as 
complex as bootstrapping a GNU compiler toolchain, I need the leanest 
solution possible.  Furthermore, I need to understand the process inside 
and out and I can only do that by figuring out and solving the problem 
myself.

>> I've gotten pretty far, although it's taken quite a long time to
>> understand the intricate dance that must be performed to bootstrap gcc
>> and glibc, and also has required some patches to glibc, mostly to get
>> past what I consider to be a deficiency in its autoconf scripts: namely,
>> that they error out on tests that check for a working linker when in
>> fact glibc ought to be buildable without any liker at all (although its
>> utility programs can't be built, but those aren't necessary during the
>> bootstrapping process).
> I've lamented this as well. It seems to me that the glib and gcc
> developers spend much of their time incrementally improving gcc and glib
> on their systems, and IMHO not enough time practicing a full bootstrap
> (let alone a cross compile).
Well I am sure that they would be happy to accept patches that are 
sensible and correct and that make the process easier.  For example, I 
added a configure option to glibc called "--disable-executables" that 
makes it easier to build glibc in a bootstrapping environment where the 
compiler can't link executables.  Once I have the whole process working 
end-to-end I will ty to get any useful patches I have produced submitted 
to the GNU people so that everyone else can hopefully benefit.

>>    At this point I can produce a working binutils
>> and glibc, but the "final" build of gcc is giving me some problems that
>> I am still working through.
> Can I as what targets you are building for? I've had some success with
> most of the targets, but building X86_64 as a cross compile has given me
> quite a bit of grief.

Right now I've only tried: BUILD=x86_64-unknown-linux-gnu, 
HOST=i686-unknown-linux-gnu, TARGET=mips-unknown-linux-gnu.  This is 
letting me exercise the script building on an X86_64 system, to build a 
toolchain that runs on an i686 system, that compiles libraries and 
programs that run on a MIPS system.  Once this works I'll test other 
combinations like BUILD=x86_64-unknown-linux-gnu, 
HOST=x86_64-unknown-linux-gnu, TARGET=i686-unknown-linux-gnu (for pure 
cross-compiler), and then one with BUILD=HOST=TARGET to test just 
building a 'normal' compiler.  Then maybe i'll try some other combinations.

>> 1. Build binutils
>> 2. Build stage1 gcc, building just the "gcc" and "install-gcc" targets,
>> not the full build (which would try to compile libraries that require
>> glibc, which has not yet been built)
>> 3. Build stage1 glibc using the stage1 gcc compiler; this uses the
>> binutils from (1) and the stage1 gcc from (2).  This version of glibc is
>> built with only static libraries and without any of the helper programs
>> of glibc, because the stage1 gcc cannot build shared libraries or
>> executables.
>> 4. Build stage2 gcc against the stage1 glibc, with executable and shared
>> library support, but without libmudflap which cannot be built against
>> the purely static stage1 glibc.
>> 5. Build final glibc with stage2 gcc, this is a complete and final glibc
>> with shared library support and support of all features.
>> 6. Build final gcc against final glibc, which is a complete gcc with
>> full support for all features.
> You might look at the makefile I attached to a mail to this list just
> yesterday - that's the sequence I'm following.
>
Thank you, I will check the archives; I just joined the list to post my 
topic and so hadn't seen your post.  I'll check it out, and once my 
script is working end-to-end (it's so close!) I'll post it for comments.

Best wishes,
Bryan