This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |