NetBSD 1.6 and forward comes equipped with an improved toolchain that can be used to easily perform system builds, new kernels, and cross compile with a relative amount of ease. In this chapter, the use of the build.sh cross compiling a kernel, cross compiling a build, and creating a release are covered. Native kernel builds are covered in Chapter 9.
Before we do anything, the sources must be retrieved. See Chapter 19 for getting the sources.
Once the sources have been obtained, the native platform tools have to be built before doing anything else. Doing this is simple, we will use the default object directory.
# mkdir /usr/obj # cd /usr/src # ./build.sh tools
If the tools have already been built and they only need updated, then the update option can be used to only rebuild tools that have changed.
# ./build.sh -u tools
Now that the native tools have been built, the tools for another target system can be created. In our example, sparc64 will be used.
# ./build.sh -m sparc64 tools
When the tools are finished building, information about them and several environment variables is printed out:
Summary of results:
build.sh command: ./build.sh -u -m sparc64 tools
build.sh started: Mon Jul 28 11:08:30 UTC 2003
Bootstrapping nbmake
MACHINE: sparc64
MACHINE_ARCH: sparc64
TOOLDIR path: /usr/src/tooldir.NetBSD-1.6U-i386
DESTDIR path: /usr/src/destdir.sparc64
RELEASEDIR path: /usr/src/releasedir
Created /usr/src/tooldir.NetBSD-1.6U-i386/bin/nbmake
makewrapper: /usr/src/tooldir.NetBSD-1.6U-i386/bin/nbmake-sparc64
Updated /usr/src/tooldir.NetBSD-1.6U-i386/bin/nbmake-sparc64
Tools built to /usr/src/tooldir.NetBSD-1.6U-i386
build.sh started: Mon Jul 28 11:08:30 UTC 2003
build.sh ended: Mon Jul 28 11:11:14 UTC 2003
Now that the tools for sparc64 have been built, it is time to cross compile the kernel.
A cross compiled kernel can be done by either going to the architecture conf directory and explicitly calling the cross compiled tools or the easier method of using build.sh.
Configuring the kernel is the same:
# cd /usr/src/sys/arch/sparc64/conf # cp GENERIC MYKERNEL
Then edit MYKERNEL. Once finished, all that needs to be done is to use build.sh to build the kernel (it will also configure it):
# cd /usr/src # ./build.sh -u -m sparc kernel=MYKERNEL
Notice that update was specified, the tools are already built, there is no reason to rebuild all of the tools. Once the kernel is built, build.sh will print out the location of it along with other information:
Summary of results:
build.sh command: ./build.sh -u -m sparc64 tools
build.sh started: Mon Jul 28 11:08:30 UTC 2003
Bootstrapping nbmake
MACHINE: sparc64
MACHINE_ARCH: sparc64
TOOLDIR path: /usr/src/tooldir.NetBSD-1.6U-i386
DESTDIR path: /usr/src/destdir.sparc64
RELEASEDIR path: /usr/src/releasedir
Created /usr/src/tooldir.NetBSD-1.6U-i386/bin/nbmake
makewrapper: /usr/src/tooldir.NetBSD-1.6U-i386/bin/nbmake-sparc64
Updated /usr/src/tooldir.NetBSD-1.6U-i386/bin/nbmake-sparc64
Building kernel without building new tools
Building kernel: MYKERNEL
Build directory: /usr/src/sys/arch/i386/compile/MYKERNEL
Kernels built from MYKERNEL:
/usr/src/sys/arch/sparc64/compile/MYKERNEL/netbsd
build.sh started: Mon Jul 28 11:08:30 UTC 2003
build.sh ended: Mon Jul 28 11:11:14 UTC 2003
By now it is probably becoming clear that the toolchain actually works in stages. First is the native tools build (which actually has a step before it, makewrappers), then a kernel. Since build.sh will attempt to rebuild the tools at every invocation, using update saves time. It is also probably clear that outside of a few options, the build.sh semantics are basically [ build.sh command ]. So, it stands to reason that creating a build and/or release, is a matter of using the right commands.
It should be no surprise that building and creating a release would look like the following:
# ./build.sh -u -m sparc build # ./build.sh -u -m sparc release
Looking at the information about environment variables (since so far only the defaults have been used), a build would be at:
/usr/src/destdir.sparc64
The release would be located at:
RELEASEDIR path: /usr/src/releasedir
Not unlike the old building method, the toolchain has a lot of variables that can be used to direct things like where certain files go, what (if any) tools are used and so on. A look in src/BUILDING covers most of them. In this section two examples of changing default variables are given in two different ways.
Many people like to track current and perform cross compiles of architectures that they use. The logic for this is simple, sometimes a new feature or device becomes available and someone may wish to use it. By keeping track of changes and building every now and again, one can be assured that they can create their own release.
It is reasonable to assume that if one is tracking and building for more than one architecture, they might want to keep the builds in a different location than the default. There are two ways to go about this, use a script to set the new DESTDIR, or simply do so interactively. In any case, it can be set the same way as any other variable (depending on your shell of course).
For the bourne or korn shells:
# export DESTDIR=/usr/builds/sparc64
For the c shell:
# setenv DESTDIR /usr/builds/shark
Simple enough. When the build is run, the binaries and files will be sent to /usr/builds.
The NetBSD Toolchain builds dynamically by default. Many users still prefer to be able to build statically. Sometimes a small system can be created without having libs is a good example of a full static build. If a particular build machine will always need one environment variable set in a particular way, then it is easiest to simply add the changed setting to /etc/mk.conf.
To make sure a build box always builds statically, simply add the following line to /etc/mk.conf:
LDSTATIC=-static