Mercurial > hg > aboriginal
changeset 809:d326c68aa747
Update website and READMEs.
author | Rob Landley <rob@landley.net> |
---|---|
date | Thu, 20 Aug 2009 22:48:42 -0500 |
parents | cce6b8e81581 |
children | 4cfa8c130605 |
files | www/downloads/README www/downloads/binaries/README www/index.html www/news.html |
diffstat | 4 files changed, 381 insertions(+), 112 deletions(-) [+] |
line wrap: on
line diff
--- a/www/downloads/README Thu Aug 20 20:18:46 2009 -0500 +++ b/www/downloads/README Thu Aug 20 22:48:42 2009 -0500 @@ -1,101 +1,96 @@ -A note about building old versions under Ubuntu 7.04 or later: --------------------------------------------------------------- +The downloads directory contains the Firmware Linux build scripts, which is +the source code for the FWL project. If you would like to build your own +cross compiler or target system image from source, use these build scripts. +They're written in bash and should be fairly easy to read. - Ubuntu 7.04 broke the /bin/sh symlink to point to the Defective Annoying - Shell (dash), which can't run the FWL scripts. - - FWL 0.2.2 and later work around this bug in Ubuntu by explicitly saying - #!/bin/bash at the start of each script. To build older FWL versions - under new Ubuntu versions, you'll have to change the "#!/bin/sh" lines - at the start of each FWL script to say "#!/bin/bash" instead. +If you want to download prebuilt binary cross compilers or system images, +see the downloads/binaries directory (which has its own README). - Here's one way to do that: - sed -i 's@^#!/bin/sh$@#!/bin/bash@' *.sh +These scripts include the following stages: + + build.sh ARCH - Other Linux distributions do not exhibit this bug. (Even MacOS X has - /bin/sh point to bash, despite using a different login shell by default.) + Top level wrapper script, calls the others in sequence. Requires one + argument, which is the target platform to build for. When run without + arguments, it lists available architectures. - Also note that User Mode Linux 2.6.20 and earlier no longer build on a modern - system because the field aio_reserved3 went away in /usr/include. (Yes, the - API exported to userspace, as used by Linux itself, is unstable.) Attempts - to build older FWL versions need to either fix that, or skip building UML. + Several environment variables can be set to control its behavior, see + the file "configure" for details. - The oldest version that builds unmodified on an ubuntu 7.10 system is - FWL 0.3.0. You can also install an older distro under qemu, and build the - older versions under that. The Red Hat 9 image available from - http://busybox.net/downloads/qemu should build all the versions before 0.3.0. + You can invoke the other scripts in sequence if you like, but this is + generally the one you use to do everything else. + + download.sh -Contents of the Firmware Linux download directory. --------------------------------------------------- - -Source tarballs: + Uses wget to download the source code required by the later build stages, + saving it in the "packages" directory. It compares the sha1 checksum + of any existing tarballs to an expected value, only downloading new + source tarballs when it needs to. - The firmware-* tarballs contain build scripts which produce a uClibc-based - cross compiler and native build environment for various target platforms. - Run "./build.sh" to see a list of target platforms, and run "./build.sh $ARCH" - to build for a given target platform. Old versions of the build script - tarballs are there for historical reasons; the newest version is probably - always the one you want. + If the primary site is down, it checks a series of fallback mirrors. + The environment variable PREFERRED_MIRROR can insert a new mirror at + the start of the list, which is checked before even the official website. + + This script is not target-specific, and only needs to be called once + when building multiple architectures. -binaries/cross-compiler: + host-tools.sh - The "binaries/cross-compiler" directory contains "host-i686" and "host-x86_64" - directories which contain prebuilt cross compilers which run on the - appropriate type of host. The i686 versions were built under Ubuntu 6.06 and - the x86_64 versions were built under Ubuntu 7.04. Each was built using the - newest release version of the build scripts, and when you run the build - yourself these tarballs should be created in the "build" directory. + Sanitizes the host environment by building known versions of needed tools + from source code, then restricting the $PATH to just those tools. This is + an optional step which can be skipped, but without it the build process + is very brittle. - Each cross-compiler-$ARCH tarball contains a compiler toolchain which - produces binaries or the given platform, linked against uClibc. (If you - just want to build uClibc binaries on an x86 host, use the toolchain in - binaries/cross-compiler/host-i686/cross-compiler-i686.tar.bz2.) + This step serves a similar purpose to the temporary system built by Linux + From Scratch's chapter 5, isolating the new system from variations in the + host. It also acts as an early check that the resulting system images + offer a sufficient development environment to rebuild themselves from + source, because the host tool versions used to build them in the first + place are the same ones the scripts install into the target root filesystem. + + This script populates the "build/host" directory, which is automatically + used by later stages if it exists. It is not target specific, and only + needs to be run once when building multiple architectures. - To use one of these compilers, extract the tarball and use the "$ARCH-gcc" - binary as your compiler, which is located in the "bin" subdirectory. You - might find it convenient to add that to your $PATH. (All the headers and - libraries for the target are located relative to $ARCH-gcc, so you can - extract the tarball anywhere you like, and move the directory it creates - anywhere, but don't move stuff around within that directory.) + cross-compiler.sh ARCH + + Creates a cross compiler for the selected target architecture, built from + gcc, binutils, uClibc, and the Linux kernel headers. - Note: This cross compiler is small and simple and only supports C. The - native compiler in mini-native supports C++ as well. - -binaries/mini-native: + The resulting compiler is assembled in build/cross-compiler-ARCH and + then packaged as an adjacent tarball of the same name. - Each mini-native-$ARCH tarball contains a minimal native root filesystem - for the given platform. This filesystem is organized as a Linux From - Scratch style /tools directory containing uClibc, a compiler, and basic - system tools (mostly busybox), designed to boot with the kernel arguments - "init=/tools/bin/sh PATH=/tools/bin". + root-filesystem.sh ARCH + + Creates a root filesystem mfor the target, built from busybox and + uClibc. Adds to it a native compiler built from the same packages as + the cross compiler, plus the packages make, bash, and distcc. - This filesystem contains a native version of gcc, which builds stuff relative - to / (not to /tools), so in order to run the compiled programs either symlink - /lib to /tools/lib, start by building and installing uClibc, or statically - link the programs you build. For more information, see - http://www.linuxfromscratch.org/lfs/view/stable/chapter06/chapter06.html + This step uses the cross compiler built in the previous step. It + assembles the new filesystem in the build/root-filesystem-ARCH directory, + then packages it as an adjacent tarball of the same name. + + system-image.sh ARCH -binaries/system-image: - - This directory contains tarballs with five files per target architecture: + Package up the root filesystem into a filesystem image (ext2, squashfs, + or initramfs), build a Linux kernel configured for the target, and + generate a wrapper script capable of invoking an appropriate emulator + (generally qemu). - image-$ARCH.ext2.bz2: a bzipped ext2 filesystem image containing the - files from the corresponding mini-native tarball. Run bunzip2 on this before - using it. + The system images are generated in build/system-image-ARCH directory, + and packaged as a tarball of the same name. - zImage-$ARCH: a bootable Linux kernel configured for use with QEMU. + run-from-build.sh ARCH - run-emulator.sh: shell script that attempts to boot the corresponding ext2 - filesystem image and Linux kernel zImage files under the emulator QEMU - (version 0.9.1 or newer). The script expects to find both files in the - current directory. + Boot up a system image under its emulator, with full native development + environment options (a 2 gigabyte /dev/hdb mounted on /home and distcc + calling out to the appropriate cross compiler). - run-with-home.sh: shell script that creates an empty 2 gigabyte ext2 image - named hdb.img, to act as a second hard drive for the emulator to mount on - /home. It then calls run-emulator.sh. (It will not recreate the image if it - already exists.) + Note that targets with the hw- prefix are aimed at actual hardware, and do + not have an emulator configured. Hardware targets are derived from an + existing architecture, repackaging the other architecture's root filesystem + with a different Linux kernel configuration. - run-with-distcc.sh: a shell script that runs a distcc server hooked up to - the cross compiler for this architecture, and calls run-with-home.sh with - extra environment variables so the development environment inside the - emulator can call out to the cross compiler for extra speed. +The wrapper script buildall.sh runs build.sh on every available target, +with extra configure options to produce additional optional stages such as +statically linked cross and native compilers.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/www/downloads/binaries/README Thu Aug 20 22:48:42 2009 -0500 @@ -0,0 +1,58 @@ +The downloads/binaries directory contains prebuilt binary images, created by +running ./buildall.sh in the most recent Firmware Linux source tarball. The +source packages for these binaries are mirrored at +"http://impactlinux.com/fwl/mirror". + +The following tarballs are found here: + +cross-compiler-ARCH.tar.bz2 + + Statically linked cross compilers which creates target binaries for + a given architecture (linked against uClibc). + + To use, extract this tarball and add its "bin" subdirectory to your $PATH, + then use the appropriate ARCH-gcc as your compiler name. + +cross-static-ARCH.tar.bz2 + + Same as the above cross-compiler tarballs, only built to run on an i686 + host and statically linked (against uClibc, this time on the host) for + maximum portability between PC Linux distributions. + + These versions include uClibc++, to support C++. Note that the i686 and + x86_64 targeted cross compilers allow you to build binaries linked against + uClibc/uClibc++ with minimal preparation. + +root-filesystem-ARCH.tar.bz2 + + Native Linux root filesystem for a given target, suitable for chrooting into + (on appropriate hardware) or packaging up into a bootable system image. It + contains busybox, uClibc, a simple boot script (usr/sbin/init.sh), and a + native toolchain with which to build additional target binaries from source. + +native-compiler-ARCH.tar.bz2 + + Statically linked version of the native compiler from root-filesystem, + which you can extract and run on an appropriate target the same way you + can extract and run the cross-compiler on the host. + + You don't need this when using FWL's root filesystem images, it provides + a native compiler for use with existing target filesystems. Again, + linking binaries against uClibc/uClibc++. + +system-image-ARCH.tar.bz2 + + Prepackaged bootable system images image for each target. + + This includes the above root-filesystem files (packaged as either ext2 or + squashfs filesystem images), an appropriately configured Linux kernel, + and a wrapper script to invoke the emulator QEMU on them. Running the + wrapper script should produce a shell prompt on the emulator's stdin/stdout + connected to the emulated system's /dev/console. + + This allows you to compile additional packages natively, generally under + QEMU. (Just wget the source tarball and build it normally.) See the file + "run-from-build.sh" in the FWL source tarball for an example of how to set + up a working native development environment with a writeable 2 gigabyte + disk image (mounted on /home) and optionally use distcc to call out to the + cross compiler to accelerate the native builds.
--- a/www/index.html Thu Aug 20 20:18:46 2009 -0500 +++ b/www/index.html Thu Aug 20 22:48:42 2009 -0500 @@ -1,6 +1,6 @@ <!--#include file="header.html" --> -<h2><a href=news.html>News: 0.9.6 release April 2, 2009</a></h2> +<h2><a href=news.html>News: 0.9.7 released August 20, 2009</a></h2> <b><h1><a href=documentation.html>What is Firmware Linux?</a></h1></b> @@ -12,7 +12,7 @@ Linux development environment for each target, runnable on real hardware or under emulators such as <a href=http://qemu.org>QEMU</a>.</p> -<p>Currently supported targets include arm, mips, powerpc, and x86, x86-64. +<p>Currently supported targets include arm, mips, powerpc, x86, and x86-64. Partial support is available for sparc, sh4, and m68k.</p> <p>For more information, see <a href=documentation.html>the documentation @@ -24,49 +24,30 @@ <blockquote> <b><h2><a href=downloads>Source Code</a></h2></b> <p>The current source tarball is -<a href=downloads/firmware-0.9.6.tar.bz2>Firmware Linux version 0.9.6</a>. +<a href=downloads/firmware-0.9.7.tar.bz2>Firmware Linux version 0.9.7</a>. This is the series of shell scripts you run to create the various binary images. See the <a href=downloads/README>README</a> for usage instructions, and the <a href=news.html>release notes</a>.</p> <p>Several <a href=downloads/binaries>prebuilt binary images</a> -are available, based on the current Firmware Linux release.</p> - -<b><h2><a href=downloads/binaries/system-image>System Images</a></h2></b> - -<p>System images provide a complete native development environment, based -on seven packages: Linux, uClibc, BusyBox, binutils, gcc, make, and bash. -(The build also uses the toybox, genext2fs, uClibc++, and distcc packages, but -does not depend on them to achieve a self-hosting OS image.)</p> +are available, based on the current Firmware Linux release. The +<a href=downloads/README>README</a> describes each tarball. The +release notes on the <a href=news.html>news page</a> explain recent +changes.</p> -<p>System image tarballs contain an ext2 root filesystem image and a kernel -configured to boot under the emulator QEMU. Use the "./run-emulator.sh" -script to use qemu to emulate the appropriate target system, giving you a -shell prompt within the native development environment. (Type "exit" when -finished.)</p> - -<b><h2><a href=downloads/binaries/mini-native>Root filesystem tarballs</a></h2></b> - -<p>If you prefer to package your own filesystem images, or use QEMU's -application emulation mode, you can download each target's root filesystem -packaged in a tarball.</p> - -<b><h2><a href=downloads/binaries/cross-compiler>Cross compilers</h2></a></b> - -<p>Prebuilt binary cross compilers for use on <a href=downloads/binaries/cross-compiler/host-i686>i686</a> or <a href=downloads/binaries/cross-compiler/host-x86_64>x86-64</a> hosts.</p> </blockquote> <b><h1><a href=/hg/firmware>Development</a></h1></b> <p>The project maintains a <a href=/hg/firmware>development repository</a> using the Mercurial source control system. This includes RSS feeds for -<a href=http://landley.net/hg/hgwebdir.cgi/firmware/rss-log>each checkin</a> -and for <a href=http://landley.net/hg/hgwebdir.cgi/firmware/rss-tags>new releases</a>.</p> +<a href=/hg/firmware/rss-log>each checkin</a> +and for <a href=/hg/firmware/rss-tags>new releases</a>.</p> <p>Questions about Firmware Linux should be addressed to the project's -<a href=http://www2.them.com:8080/cgi-bin/mailman/listinfo/firmware>mailing -list</a>, the IRC channel #firmware on irc.freenode.org. The project -maintainer's <a href=/notes.html>blog</a> often includes notes about +<a href=http://lists.impactlinux.com/listinfo.cgi/firmware-impactlinux.com>mailing +list</a>, or the IRC channel #firmware on irc.freenode.org. The project +maintainer's <a href=http://landley.net/notes.html>blog</a> often includes notes about ongoing Firmware Linux development.</p> <!--#include file="footer.html" -->
--- a/www/news.html Thu Aug 20 20:18:46 2009 -0500 +++ b/www/news.html Thu Aug 20 22:48:42 2009 -0500 @@ -1,6 +1,241 @@ <!--#include file="header.html" --> + <b><h1>News</h1></b> +<h2>August 20, 2009</h2> +<p><a href=downloads/firmware-0.9.7.tar.bz2>Version 0.9.7</a> is out, a little +over a month and a half late. It's a larger update than usual, so the +release notes are a bit long.</p> + +<p>This release is based on +<a href=http://impactlinux.com/hg/firmware/log/807>mercurial version 807</a> +of the build scripts, +and includes <b>Linux 2.6.30.4</b> and <b>BusyBox 1.14.3</b>. +No new uClibc release is out since last time.</p> + +<p>Lots of little bugs got fixed. For example, this release should build on +Fedora 11 (and any other platform that hasn't got "which" installed by +default), and now supports distcc and ccache on the host (and will use them +automatically if they are installed).</p> + +<h3><b>Changes to build stages: new root-filesystem, cross-static, and +native-compiler tarballs, upgraded buildall.sh and smoketest-all.sh.</b></h3> + +<blockquote> +<p>The old "mini-native" stage has been renamed "root-filesystem" +(the same way package-mini-native became system-image last release). The +script names (and resulting tarballs) now indicate what each stage makes. +So build.sh calls host-tools.sh, cross-compiler.sh, root-filesystem.sh, +and system-image.sh, in that order.</p> + +<p>Th old build-static-toolchains.sh script is gone, with its functionality +integrated into buildall.sh (which now builds i686 hosted static toolchains +for each target by default). This is implemented by two new environment +variables triggering optional behavior: STATIC_CROSS_COMPILER_HOST +and BUILD_STATIC_NATIVE_COMPILER.</p> + +<p>Setting STATIC_CROSS_COMPILER_HOST to an architecture name creates a +cross compiler statically linked to run on that host (via a technique +known as canadian cross compile). For example, the invocation:</p> + +<blockquote> +<p>BUILD_CROSS_COMPILER_HOST=i686 ./build.sh armv4l</P> +</blockquote> + +<p>Would create a tarball called "cross-static-armv4l.tar.bz2" which was +built to run on an i686 host, and was statically linked (against uClibc) +on that host to be distribution independent.</p> + +<p>Setting BUILD_STATIC_NATIVE_COMPILER to any non-empty value creates a +native compiler for the target (packaged as native-compiler-$ARCH.tar.bz2), +which is statically linked against uClibc so it can be extracted and run on +just about any system of the appropriate type. (So if you can get a Linux +shell prompt and have enough storage and memory, you should be able to +compile stuff.)</p> + +<p>The upgraded smoketest-all.sh script runs smoketest.sh on each +target built. (The smoketest.sh script attempts to compile and run "hello +world" natively within a system image under qemu, and indicates whether or +not it worked via "pass" or "fail".) Note that smoketest-all.sh now +autodetects which targets have been built (have system images in the build +directory), and smoketest.sh times out after 60 seconds so targets that hang +will return failure eventually.</p> + +</blockquote> + +<h3><b>Squashfs 4.0 now the default system image type</b></h3> + +<blockquote> +<p>The root filesystem image type is now squashfs by default. (To change it set +SYSIMAGE_TYPE to ext2 or initramfs, either in your environment or the file +"configure".)</p> + +<p>This involved upgrading the userspace squashfs support package +to the version 4.0 supported by the upstream kernel, and numerous small fixes +to work with a read-only root filesystem (with writeable spaced mounted on +/home and /tmp).</p> +</blockquote> + +<h3><b>Target upgrades</b></h3> +<blockquote> +<h3><b>ARM upgrades</b></h3> + +<blockquote> +<p>Lots of work on the arm targets, with the addition of a new armv6l target +and conversion of the armv5l target to +<a href=http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI-matters/>ARM EABI</a> (which used to be documented <a href=http://www.arm.com/products/DevTools/ABI.html>here</a>, +but ARM screwed up its website and now you have to go +<a href=http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html>here</a>). The armv4l target still provides an ARM v4 +little endian soft float OABI target (which is "the i386 of ARM", meaning it +should run on just about any arm hardware, if a bit slowly). A new +armv4be target is the same as armv4l except big endian.</p> + +<p>A new hw-tct-hammer target supports the <a href=http://www.tincantools.com/product.php?productid=16143>Tin Can Tools hammer/nail board</a>.</p> +</blockquote> + +<h3><b>Updated sparc support, almost works now. (uClibc for sparc still sucks.)</b></h3> + +<blockquote> +<p>The sparc target has also been upgraded to the point where it now gives +a shell prompt. (And immediately dies with a bus error or a hang if you try +to do anything, because uClibc for sparc still doesn't work. The "upgrade" +consisted of statically linking everything because uClibc's dynamic loader +doesn't work for sparc.)</p> +</blockquote> + +<h3><b>PowerPC remains fiddly due to QEMU issues, new powerpc-440fp target</b></h3> + +<blockquote> +<p>PowerPC support in QEMU is +<a href=http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg01007.html>officially unstable</a>, so although FWL's powerpc target hasn't significantly +changed from last release, the version of QEMU in source control no longer +runs it (nor the binary powerpc system images released with FWL 0.9.6) and +QEMU's developers do not consider this a regression. While we search for a new +Linux kernel .config that matches QEMU's current expectations (and await a +release considered "stable"), note that setting HOST_BUILD_EXTRA=1 before +running host-tools.sh will build a version of qemu that does run powerpc and +put it in build/host where run-from-build.sh can find it. (Note also that +building qemu from source still takes significantly longer than the rest of the +host-tools.sh stage combined.)</p> + +<p>A new powerpc-440fp target produces code for the powerpc 440 with hardware +floating point. (Theoretically QEMU's "bamboo" board emulation should +run this, but QEMU doesn't emulate a 440 processor yet. We compromise by +running a ppc440 filesystem under qemu's power mac emulation, to take +advantage of the ppc440 instruction set being almost a subset of full powerpc. +This gets us a shell prompt, but throws illegal instruction errors if you +try to do anything fancy.)</p> + +<p>(Note that powerpc-440fp is not a hw-target for powerpc, it's a different +processor instruction set like i586 vs i686. Alas, one that qemu doesn't +properly emulate yet.)</p> + +</blockquote> + +</blockquote> + +<h3><b>Now using last GPLv2 release of GCC, and future plans</b></h3> + +<blockquote> +<p>The upgrade to <b>gcc 4.2.1</b> gives us +<a href=http://gcc.gnu.org/ml/gcc-announce/2007/msg00003.html>the last +GPLv2 licensed version of gcc</a> (thus avoiding +<a href=http://lwn.net/Articles/343608/>various problems</a>). +<a href=http://savannah.gnu.org/forum/forum.php?forum_id=4932>Make 3.81</a> +was already the last GPLv2 release of that project.</p> + +<p>Note that <b>bash 2.05b</b> is still intentionally ancient (to avoid the +bloat of 3.x), and may be replaced with busybox ash as the default FWL shell +in a future release. Similarly, although <b>binutils 2.17</b> was the last +GPLv2 version from the FSF, an upgrade to +<a href=http://ftp.kernel.org/pub/linux/devel/binutils/release.binutils-2.18.50.0.1>the +last GPLv2 release of Red Hat's binutils fork, 2.17.5.0.17</a> is under +consideration for a future release. But mostly the GNU compiler toolchain +has been upgraded as far as possible for the forseeable future, either because +new versions provide no significant benefits or because they're not available +under a license compatible with the Linux kernel's.</p> + +<p>Future upgrades to these packages will either be via individual patches +(maintaining GPLv2 license) or by investigating alternative non-FSF +packages such as OpenBSD's <a href=http://lwn.net/Articles/255558>PCC</a> or +Apple's <a href=http://llvm.org>LLVM</a>. In preparation for support of +alternate compilers, the build scripts have moved from using "gcc" to the +more generic "cc" for the compiler name wherever possible, but currently no +drop-in replacement compiler is available.</p> + +</blockquote> + +<h3><b>Implementation details</b></h3> + +<blockquote> +<p>Each target configuration renamed "details" to "settings", and added +a "description". (This makes Gentoo From Scratch's kconfig easier.)</p> + +<p>The download.sh stage now populates a "packages" directory instead of +"sources/packages", meaning that everything in the sources directory now +comes from the FWL source tarball. To do the equivalent of "make clean" +you can "rm -rf build", and to do a "make distclean" you can +"rm -rf packages build".</p> + +<p>The build no longer deletes the alt-* tarballs when UNSTABLE isn't +set, you must do that by hand if you want an updated alt- version of a +package. The packages/MANIFEST file creation can now use the extended +tarball information to detect git version numbers.</p> + +<p>The === bars now show the current stage name and architecture each +package is being built for. (Pipe the build output to grep "^===" to see +just the start of each new package build.) The same information is sent +to the title bar of your xterm, export NO_TITLE_BAR=1 if you don't want the +build to update the title bar.</p> + +<p>The BUILD_STATIC option now applies to all packages built in +root-filesystem.sh, and can be set from a target configuration's settings file +(as sparc is now doing).</p> + +<p>The BUILD_VERBOSE option passes V=1 to the linux, busybox, and uClibc +builds that otherwise sanitize their output.</p> + +<p>You can now set NATIVE_TOOLCHAIN=only to build just the compiler +and not the other parts (busybox, make, toybox, bash...) This is used +by the canadian cross steps in build.sh to create static cross and native +compilers.</p> + +<p>This release broke up scripts/include.sh so that script just +sets lots of environment variables, and now includes scripts/functions.sh +to define shell functions. The architecture setup (reading architecture +files and creating temporary directories and such) is now done via the +"read_arch_dir $ARCH" shell function, so merely including sources/include.sh +should no longer have significant side effects. Similarly, setupfor now +has an EXTRACT_ONLY environment variable instead of depending on a blank +$ARCH (which host-tools.sh has, despite wanting to snapshot source so it can +build stuff).</p> + +<p>Various fixes to make parallel builds work better. (So it neither leaves +background processes running nor kills the parent shell and closes your +xterm when you hit ctrl-c.) The new "killtree" shell function, +which kills a process and all its children and grandchildren recursively with +pgrep. We also build our own sources/toys/mysetsid.c program with the host +compiler (because the normal command line "setsid" doesn't also do a tcsetpgrp +on stdin so signal handling isn't forwarded to the new session). This should +more reliably allow ctrl-c to exit smoketest.sh and system-image.sh and such, +and let FORK=1 ./buildall.sh stop all its background processes when +interrupted. (Note that smoketest-all.sh also honors FORK=1.)</p> + +<p>The logs from buildall.sh now live in build/logs.</p> + +<p>The new config option ROOT_NODIRS avoids creating the normal set of empty +directories in the new root filesystem. (The old /tools support went +away, but a BUILD_STATIC ROOT_NODIRS build can be extracted into /tools +and used from there. Then either symlink "/lib" to "/tools/lib" or "export +UCLIBC_DYNAMIC_LINKER=/tools/lib/ld-uClibc.so.0" to add more stuff to +/tools natively.)</p> + +<p>The compiler wrapper (sources/toys/ccwrap.c) can now use +architecture-specific WRAPPER_TOPDIR values. (I.E. armv4l-cc could +"export armv4l_WRAPPER_TOPDIR=/path/to/directory".) This makes +canadian cross compiles a lot easier.</p> +</blockquote> + <h2>April 2, 2009</h2> <p><a href=downloads/firmware-0.9.6.tar.bz2>Version 0.9.6</a> includes Linux 2.6.29 and uClibc 0.9.30.1, now with support for sh4 and upgraded powerpc