Re: [crosstool-NG] Design discussion

[Rob Landley <rob at landley dot net>]

On Sunday 05 April 2009 17:45:30 Rob Landley wrote:
> F) Running ./configure with no arguments died because awk doesn't call
> itself gawk, and that's where I punted until I felt more awake.  The "fight
> with getting it installed again" was:
>
>   1) Run ./configure, watch it die, install gawk.
>   2) Run ./configure, watch it die, install bison.
>   3) Run ./configure, watch it die, install flex.
>   4) Run ./configure, watch it die, try to install makeinfo, realize that
> ubuntu hasn't got a package called makeinfo, install its suggestion
> of "texi2html", find out that ./configure still claims it hasn't got
> makeinfo, do "aptitude search makeinfo" and come up with nothing, think for
> a bit remember that ubuntu has a fiddly thing its shell does when you
> mistype a command to suggest some random package you could install that
> will give you an "sl" command, type makeinfo at the command line, have it
> suggest texinfo, install texinfo.
>   5) Run ./configure, watch it die, install automake.
>   6) Run ./configure, watch it die, install libtool.

Note that part of my complaint here is it doesn't tell you _all_ the things it 
needs, it just dies at the first one and forces you to fix each one 
individually and repeat the process half a dozen times to find out the rest.

(That's aside from every single one of the above being demonstrably 
unnecessary to build a working cross compiler.)

> And _then_ it tells me it wants to install in /usr/local, which I can work
> around with --prefix=`pwd` or its synonym --local, except I did
> `pwd`/subdir because I wanted to see what it was actually installing.

For comparison purposes, let me tell you how I dealt with this set of problems 
on my system.  Some of my design goals were:

1) Don't pester the user with unnecessary questions.  (Let them override your 
defaults, but it should just work out of the box.)

2) Don't ever require root access.  Do everything as a normal user.  
(Including setting up the environment for build prerequisites.)

3) Isolate the build from variations in the host.  The host needs bash to run 
the scripts and a working toolchain, ,but don't assume it has _anything_ else 
installed.

4) Keep your dependencies down to an absolute minimum.  The more you depend 
on, the more there is to go wrong.

5) Don't let the build vary if the host has _extra_ things installed.  For 
example, the ./configure of distcc will build extra functionality if it 
detects python is installed.  So don't its ./configure _find_ python.  
(Without this, your build isn't properly reproducible on different systems 
because you don't know what your dependencies actually are.  Don't let the 
build use anything it doesn't actually need, and doesn't explicitly include.)

Ok, now how's that implemented?

Firmware Linux hasn't got a ./configure stage, or menuconfig.  You can 
configure it by editing the file "configure", but everything in there is 
optional and you shouldn't have to worry about it your first time running the 
thing.  To use it, you download the tarball, extract it, and 
run "./build.sh".  (There's a README that walks you through this.)

The second script build.sh runs (after download.sh) is host-tools.sh.  (I 
mentioned it here last time.)  What host-tools.sh does is populate a 
directory (build/host) with all the commands the rest of the build will need, 
and then sets "PATH=/path/to/build/host" and nothing else.  This isolates the 
build from variations in the host system.  Instead of forcing you to modify 
your host to be able to run the build, the build assumes an absolute minimum 
environment and builds up from there to what it needs.

Here's how host-tools.sh works:

First, you need a host toolchain in order to build anything else.  This is a 
chicken and egg problem; we can't build a host toolchain from source unless 
we've already got one to build it with.  So the one you already have 
installed had better work, and building another one is just redundant.

So for the host toolchain, host-tools.sh creates symlinks to the host's 
existing commands:

  for i in ar as nm cc gcc make ld
  do
    [ ! -f "${HOSTTOOLS}/$i" ] &&
      (ln -s `PATH="$OLDPATH" which $i` "${HOSTTOOLS}/$i" || dienow)
  done

Notice it doesn't symlink "strip".  The reason for this is that using the host 
strip during cross compilation is a common mistake, you're supposed to use 
the target $ARCH-strip command.  So not having the host strip in the $PATH is 
an easy way to catch that one, and it's not hard to adjust the packages we're 
building for the host not to need strip (either by building with -s or just 
using the unstripped versions on the host, where disk space is easy to come 
by).

Then host-tools.sh builds a defconfig busybox and installs all those commands 
into build/host.  The reason it does this is so that A) we're building with 
known versions of all these tools, which have been previously tested and are 
known to work, B) it's an easy smoke test to confirm that we can rebuild all 
this stuff under the tools we're installing into the target system.  (The 
resulting build environment will have the busybox versions of these tools.  
If we can't build with 'em now, we won't be able to build with them in the 
target system, so we need to know whether or not they work.)

Then host-tools.sh builds and installs a few other things (such as distcc, 
genext2fs/e2fsprogs, and squashfs) which are really optional and can be 
ignored here.  You don't need them to build the cross compiler or the root 
filesystem.  Either ext2 or squashfs is needed to create a system image, 
depending on what target filesystem type you select (it defaults to ext2).

Now all of this is optional.  You can skip the host-tools.sh script and it 
won't adjust the $PATH, in which case cross-compiler.sh, mini-native.sh, and 
system-image.sh will use whatever $PATH and whatever tools you have installed 
in it.  But then it's your problem making sure your host has everything it 
needs to have installed (note that by default, ubuntu doesn't even install 
the "patch" command), and nothing extra that will confuse the build.  Also, 
if anything is _going_ to break, it's generally host-tools.sh.  Once that's 
finished, the rest of the build should run to completion unless something's 
_really_ wrong with your environment (out of disk space, out of memory, your 
host compiler is broken, etc.)

Also note that all this is implementation details.  It's called automatically 
by build.sh, and people who just want to kick out a toolchain don't have to 
care about any of it.

Rob

P.S.  I am oversimplifying what host-tools does slightly.  For example, I 
skipped over the fact it can build qemu, which is never needed to build 
anything I've discussed, but can be used as a smoke test to run a "hello 
world" program built with the new cross compiler, and it can also be used to 
_run_ the completed system images.

I also skipped over how if you set the environment variable RECORD_COMMANDS 
(it's one of the options in the "config" file), then instead of populating a 
host directory with new commands, it'll create a directory of symlinks to a 
wrapper that logs the command line and then calls the original command.  This 
way you can grep through the log to see every single command the entire build 
ran, and get a list of all the command line utilities it needed so you can 
audit what you're actually using.  Note that this will miss #!/bin/bash style 
script interpreter calls, but there aren't very many of those.

That's one of those "more complexity exists, but you have to dig for it" style 
things.  You have to read either 
http://impactlinux.com/fwl/documentation.html or the comments in "config" to 
find out about this at all.  Newbies aren't confronted with it.
-- 
GPLv3 is to GPLv2 what Attack of the Clones is to The Empire Strikes Back.

--
For unsubscribe information see http://sourceware.org/lists.html#faq