Re: Toolchain bootstrapping advice needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux