Chapter 33. Crosscompiling NetBSD with

Table of Contents

33.1. Building the toolchain
33.2. Configuring the kernel manually
33.3. Building the kernel manually
33.4. Building the kernel with
33.5. Building the userland
33.6. Building the X Window System
33.7. Changing build behaviour
33.7.1. Changing the Destination Directory
33.7.2. Static Builds
33.7.3. Using options
33.7.4. make(1) variables used during build

NetBSD uses a framework,, to build both the operating system's kernel and the whole userland for either the same platform as the host machine, or for a different platform, using cross-compilation. will take care of creating all the tools required to build NetBSD for a given platform, and make them available ready to use for development work.

In this chapter, we will show how to use to first create a toolchain, including compiler, assembler, linker and so on, then use it to cross-compile a NetBSD kernel and userspace for AArch64 on an AMD64 host machine. While native kernel builds are covered in Chapter 34, Compiling the kernel, using the script is generally preferred for building the entire of NetBSD.

Before starting, we have placed the sources in a subdirectory of our user's home directory: /home/nia/cvs/src. While /usr/src is the traditional location for NetBSD sources, as described in Chapter 32, Obtaining the sources, we would like to build the operating system as an unprivileged (non-root) user.

A more detailed description of the framework can be found in Luke Mewburn and Matthew Green's paper and their presentation from BSDCon 2003 as well as in /usr/src/BUILDING.

33.1. Building the toolchain

The first step to do cross-development is to get all the necessary tools available. In NetBSD terminology, this is called the "toolchain", and it includes BSD-compatible make(1), C/C++ compilers, linker, assembler, config(8), as well as a fair number of tools that are only required when crosscompiling a full NetBSD release, which we won't cover here.

The command to create the toolchain is quite simple, using NetBSD's src/ script. Please note that all the commands here can be run as normal (non-root) user:

$ cd /home/nia/cvs/src
$ ./ -U -O ~/obj -j2 -m evbarm -a aarch64 tools
  • The "-U" option indicates we are doing an unprivileged build, as a non-root user, typically with the source code located somewhere other than /usr/src

  • The "-O" option specifies the directory to use for compiled object files.

  • The "-j2" option specifies the number of parallel builds to run. You may wish to set this to the number of CPU cores on your host system.

  • The "-m evbarm -a aarch64" options indicate we are building for a machine type of evbarm with a CPU type of aarch64. You can list the available machines and CPU types:

    $ ./ list-arch

If the tools have been built previously and they only need to be updated, then the update option "-u" can be used to only rebuild tools that have changed:

$ ./ -U -u -O ~/obj -j2 -m evbarm -a aarch64 tools

When the tools are built, information about them and several environment variables is printed out:

===> Tools built to /home/nia/obj/tooldir.NetBSD-9.99.81-amd64
===> ended:      Sun Apr 18 12:10:58 CEST 2021
===> Summary of results: command:    ./ -U -u -O /home/nia/obj -j2 -m evbarm -a aarch64 tools started:    Sun Apr 18 11:17:46 CEST 2021
         NetBSD version:      9.99.81
         MACHINE:             evbarm
         MACHINE_ARCH:        aarch64
         Build platform:      NetBSD 9.99.81 amd64
         HOST_SH:             /bin/sh
         No $TOOLDIR/bin/nbmake, needs building.
         Bootstrapping nbmake
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /home/nia/obj/tooldir.NetBSD-9.99.81-amd64
         DESTDIR path:        /home/nia/obj/destdir.evbarm
         RELEASEDIR path:     /home/nia/obj/releasedir
         Created /home/nia/obj/tooldir.NetBSD-9.99.81-amd64/bin/nbmake
         Updated makewrapper: /home/nia/obj/tooldir.NetBSD-9.99.81-amd64/bin/nbmake-evbarm
         Tools built to /home/nia/obj/tooldir.NetBSD-9.99.81-amd64 ended:      Sun Apr 18 12:10:58 CEST 2021

During the build, object directories are used consistently, i.e. special directories are kept that keep the platform-specific object files and compile results. In our example, they will be kept in directories named "obj.evbarm" as we build for AArch64 as target platform.

The toolchain itself is part of this, but as it's hosted and compiled for an amd64 system, it will get placed in its own directory indicating where to cross-build from. Here's where our toolchain is located:

$ pwd
$ ls -d ~/obj/tooldir*

So, the general rule of thumb is for a given "host" and "target" system combination, the cross-compiler will be placed in the "" directory by default. A full list of all tools created for cross-compiling the whole NetBSD operating system includes:

$ ls ~/obj/tooldir.NetBSD-9.99.81-amd64/bin
aarch64--netbsd-addr2line    nbconfig                     nbmkcsmapper
aarch64--netbsd-ar           nbcrunchgen                  nbmkdep
aarch64--netbsd-as           nbctags                      nbmkesdb
aarch64--netbsd-c++          nbctfconvert                 nbmklocale
aarch64--netbsd-c++filt      nbctfmerge                   nbmknod
aarch64--netbsd-cpp          nbcvslatest                  nbmktemp
aarch64--netbsd-dbsym        nbdb                         nbmkubootimage
aarch64--netbsd-elfedit      nbdisklabel                  nbmsgc
aarch64--netbsd-fdisk        nbdtc                        nbmtree
aarch64--netbsd-g++          nbeqn                        nbnroff
aarch64--netbsd-gcc          nbfile                       nbpax
aarch64--netbsd-gcc-9.3.0    nbgenassym                   nbpaxctl
aarch64--netbsd-gcc-ar       nbgencat                     nbperf
aarch64--netbsd-gcc-nm       nbgmake                      nbpic
aarch64--netbsd-gcc-ranlib   nbgpt                        nbpwd_mkdb
aarch64--netbsd-gcov         nbgrep                       nbrefer
aarch64--netbsd-gcov-dump    nbgroff                      nbrpcgen
aarch64--netbsd-gcov-tool    nbhexdump                    nbsed
aarch64--netbsd-install      nbhost-mkdep                 nbslc
aarch64--netbsd-ld           nbindxbib                    nbsoelim
aarch64--netbsd-ld.bfd       nbinstall-info               nbsortinfo
aarch64--netbsd-mdsetimage   nbinstallboot                nbstat
aarch64--netbsd-nm           nbjoin                       nbstrfile
aarch64--netbsd-objcopy      nblex                        nbsunlabel
aarch64--netbsd-objdump      nbllvm-tblgen                nbtbl
aarch64--netbsd-ranlib       nblorder                     nbtexi2dvi
aarch64--netbsd-readelf      nbm4                         nbtexi2pdf
aarch64--netbsd-size         nbmake                       nbtexindex
aarch64--netbsd-strings      nbmake-evbarm                nbtic
aarch64--netbsd-strip        nbmakefs                     nbtsort
nbasn1_compile               nbmakeinfo                   nbuudecode
nbawk                        nbmakekeys                   nbxz
nbcap_mkdb                   nbmakestrs                   nbyacc
nbcat                        nbmakewhatis                 nbzic
nbcksum                      nbmandoc
nbcompile_et                 nbmenuc

As you can see, most of the tools that are available native on NetBSD are present with some program prefix to identify the target platform for tools that are specific to a certain target platform.

One important tool that should be pointed out here is "nbmake-evbarm". This is a shell wrapper for a BSD compatible make(1) command that's setup to use all the right commands from the cross-compilation toolchain. Using this wrapper instead of /usr/bin/make allows crosscompiling programs that were written using the NetBSD Makefile infrastructure (see src/share/mk). We will use this make(1) wrapper in a second to cross compile the kernel!

33.2. Configuring the kernel manually

Now that we have a working toolchain available, the "usual" steps for building a kernel are needed - create a kernel config file, run config(1), then build. As the config(1) program used to create header files and Makefile for a kernel build is platform specific, we need to use the "nbconfig" program that's part of our new toolchain. That aside, the procedure is just as like compiling a "native" NetBSD kernel. Commands involved here are:

$ cd /home/nia/cvs/src/sys/arch/evbarm/conf
$ /home/nia/obj/tooldir.NetBSD-9.99.81-amd64/bin/nbconfig MYKERNEL

That's all. This command has created a directory ../compile/MYKERNEL with a number of header files defining information about devices to compile into the kernel, a Makefile that is setup to build all the needed files for the kernel, and link them together.

33.3. Building the kernel manually

We have all the files and tools available to crosscompile our AArch64-based kernel from our Intel-based host system, so let's get to it! After changing in the directory created in the previous step, we need to use the toolchain's nbmake-evbarm shell wrapper, which just calls make(1) with all the necessary settings for crosscompiling for an AArch64 platform:

$ cd ../compile/MYKERNEL/
$ /home/nia/obj/tooldir.NetBSD-9.99.81-amd64/bin/nbmake-evbarm depend
$ /home/nia/obj/tooldir.NetBSD-9.99.81-amd64/bin/nbmake-evbarm

This will churn away a bit, then spit out a kernel:

   text    data     bss     dec     hex filename                       
11131832        3627920 1738912 16498664         fbbfe8 netbsd
$ ls -lh netbsd
-rwxr-xr-x  1 nia  wheel   16M Apr 18 12:46 netbsd
$ file netbsd
netbsd: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, for NetBSD 9.99.81, not stripped


Since we are building for AArch64, a few other kernel images in different formats were built, including netbsd.img and netbsd.bin for the U-Boot /boot partition. On systems with more standard boot procedures, you only need to worry about netbsd.

Now the kernel in the file netbsd can be transferred to a machine (via scp, rsync, etc.) and booted.

After configuring and crosscompiling the kernel, the next logical step is to crosscompile the whole system, and bring it into a distribution-ready format. Before doing so, an alternative approach to crosscompiling a kernel will be shown in the next section, using the script to do configuration and crosscompilation of the kernel in one step.

33.4. Building the kernel with

A cross compiled kernel can be done manually as described in the previous sections, or by the easier method of using, which will be shown here.

Preparation of the kernel config file is the same as described above:

$ cd /home/nia/cvs/src/sys/arch/evbarm/conf

Then edit MYKERNEL and once finished, all that needs to be done is to use to build the kernel (it will also configure it, running the steps shown above):

$ cd /home/nia/cvs/src
$ ./ -U -u -j2 -O ~/obj -m evbarm -a aarch64 kernel=MYKERNEL

Notice that update ("-u") was specified, the tools are already built, there is no reason to rebuild all of the tools. Once the kernel is built, will print its location, along with other information:

===> Summary of results: command:    ./ -O /home/nia/obj -U -u -j2 -m evbarm -a aarch64 kernel=MYKERNEL started:    Sun Apr 18 12:25:16 CEST 2021
         NetBSD version:      9.99.81
         MACHINE:             evbarm
         MACHINE_ARCH:        aarch64
         Build platform:      NetBSD 9.99.81 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /home/nia/obj/tooldir.NetBSD-9.99.81-amd64
         DESTDIR path:        /home/nia/obj/destdir.evbarm
         RELEASEDIR path:     /home/nia/obj/releasedir
         Updated makewrapper: /home/nia/obj/tooldir.NetBSD-9.99.81-amd64/bin/nbmake-evbarm
         Building kernel without building new tools
         Building kernel:     MYKERNEL
         Build directory:     /home/nia/obj/sys/arch/evbarm/compile/MYKERNEL
         Kernels built from MYKERNEL:
          /home/nia/obj/sys/arch/evbarm/compile/MYKERNEL/netbsd ended:      Sun Apr 18 12:46:26 CEST 2021
===> .

The path to the kernel built is of interest here: /home/nia/obj/sys/arch/evbarm/compile/MYKERNEL/netbsd, it can be used the same way as described above.

33.5. Building the userland

By now it is probably becoming clear that the toolchain actually works in stages. First the toolchain is built, then a kernel. Since will attempt to rebuild the tools at every invocation, using update saves time. It is probably also clear that outside of a few options, the semantics are basically command. So, it stands to reason that building the whole userland and/or a 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:

$ ./ -U -u -j2 -O ~/obj -m evbarm -a aarch64 release

These commands will compile the full NetBSD userland and put it into the destination object directory, and then build a release from it in a release subdirectory.

33.6. Building the X Window System

The NetBSD project has its own copy of the X Window System's which contains changes to make X function well on as many of the platforms supported by NetBSD as possible. Due to this, it is desirable to use the X Window System version available from and for NetBSD, which can also be crosscompiled much like the kernel and base system. To do so, the "xsrc" sources must be checked out from CVS into just as "src" and "pkgsrc" were as described in Chapter 32, Obtaining the sources.

After this, X can be crosscompiled for the target platform by adding the -x switch to, e.g. when creating a full release:

$ ./ -U -u -O ~/obj -j2 -x -X /home/nia/cvs/xsrc -m evbarm -a aarch64 release

The -x option automatically sets the variable to build X11, and -X points to the directory containing the X11 sources.

33.7. Changing build behaviour

The build system 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 some examples of changing default settings are given, each following its own ways.

33.7.1. Changing the Destination Directory

Many people like to track NetBSD-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 these architectures can build 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, either 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 sh(1), or ksh(1), this is:

$ export DESTDIR=/usr/builds/evbarm-aarch64

For csh(1), the command is:

$ setenv DESTDIR /usr/builds/evbarm-aarch64

Simple enough. When the build is run, the binaries and files will be sent to /usr/builds.

33.7.2. Static Builds

The NetBSD toolchain builds and links against shared libraries by default. Many users still prefer to be able to link statically. Sometimes a small system can be created without having shared libraries, which is a good example of doing 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:


33.7.3. Using options

Besides variables in environment and /etc/mk.conf, the build process can be influenced by a number of switches to the script itself, as we have already seen when forcing unprivileged (non-root) builds, selecting the target architecture or preventing deletion of old files before the build. All these options can be listed by running -h:

$ cd /home/nia/cvs/src
$ -h

Usage: [-EhnoPRrUuxy] [-a arch] [-B buildid] [-C cdextras]
                [-c compiler] [-D dest] [-j njob] [-M obj] [-m mach]
                [-N noisy] [-O obj] [-R release] [-S seed] [-T tools]
                [-V var=[value]] [-w wrapper] [-X x11src] [-Y extsrcsrc]
                [-Z var]
                operation [...]

 Build operations (all imply "obj" and "tools"):
    build               Run "make build".
    distribution        Run "make distribution" (includes DESTDIR/etc/ files).
    release             Run "make release" (includes kernels & distrib media).

 Other operations:
    help                Show this message and exit.
    makewrapper         Create nbmake-${MACHINE} wrapper and nbmake.
                        Always performed.
    cleandir            Run "make cleandir".  [Default unless -u is used]
    dtb                 Build devicetree blobs.
    obj                 Run "make obj".  [Default unless -o is used]
    tools               Build and install tools.
    install=idir        Run "make installworld" to `idir' to install all sets
                        except `etc'.  Useful after "distribution" or "release"
    kernel=conf         Build kernel with config file `conf'
    kernel.gdb=conf     Build kernel (including netbsd.gdb) with config
                        file `conf'
    releasekernel=conf  Install kernel built by kernel=conf to RELEASEDIR.
    kernels             Build all kernels
    installmodules=idir Run "make installmodules" to `idir' to install all
                        kernel modules.
    modules             Build kernel modules.
    rumptest            Do a linktest for rump (for developers).
    sets                Create binary sets in
                        DESTDIR should be populated beforehand.
    distsets            Same as "distribution sets".
    sourcesets          Create source sets in RELEASEDIR/source/sets.
    syspkgs             Create syspkgs in
    iso-image           Create CD-ROM image in RELEASEDIR/images.
    iso-image-source    Create CD-ROM image with source in RELEASEDIR/images.
    live-image          Create bootable live image in
    install-image       Create bootable installation image in
    disk-image=target   Create bootable disk image in
    params              Display various make(1) parameters.
    list-arch           Display a list of valid MACHINE/MACHINE_ARCH values,
                        and exit.  The list may be narrowed by passing glob
                        patterns or exact values in MACHINE or MACHINE_ARCH.

    -a arch        Set MACHINE_ARCH to arch.  [Default: deduced from MACHINE]
    -B buildid     Set BUILDID to buildid.
    -C cdextras    Append cdextras to CDEXTRA variable for inclusion on CD-ROM.
    -c compiler    Select compiler:
                   [Default: gcc]
    -D dest        Set DESTDIR to dest.  [Default: destdir.MACHINE]
    -E             Set "expert" mode; disables various safety checks.
                   Should not be used without expert knowledge of the build
    -h             Print this help message.
    -j njob        Run up to njob jobs in parallel; see make(1) -j.
    -M obj         Set obj root directory to obj; sets MAKEOBJDIRPREFIX.
                   Unsets MAKEOBJDIR.
    -m mach        Set MACHINE to mach.  Some mach values are actually
                   aliases that set MACHINE/MACHINE_ARCH pairs.
                   [Default: deduced from the host system if the host
                   OS is NetBSD]
    -N noisy       Set the noisyness (MAKEVERBOSE) level of the build:
                       0   Minimal output ("quiet")
                       1   Describe what is occurring
                       2   Describe what is occurring and echo the actual
                       3   Ignore the effect of the "@" prefix in make commands
                       4   Trace shell commands using the shell's -x flag
                   [Default: 2]
    -n             Show commands that would be executed, but do not execute them.
    -O obj         Set obj root directory to obj; sets a MAKEOBJDIR pattern.
                   Unsets MAKEOBJDIRPREFIX.
    -o             Set MKOBJDIRS=no; do not create objdirs at start of build.
    -P             Set MKREPRO and MKREPRO_TIMESTAMP to the latest source
                   CVS timestamp for reproducible builds.
    -R release     Set RELEASEDIR to release.  [Default: releasedir]
    -r             Remove contents of TOOLDIR and DESTDIR before building.
    -S seed        Set BUILDSEED to seed.  [Default: NetBSD-majorversion]
    -T tools       Set TOOLDIR to tools.  If unset, and TOOLDIR is not set in
                   the environment, nbmake will be (re)built
    -U             Set MKUNPRIVED=yes; build without requiring root privileges,
                   install from an UNPRIVED build with proper file permissions.
    -u             Set MKUPDATE=yes; do not run "make cleandir" first.
                   Without this, everything is rebuilt, including the tools.
    -V var=[value] Set variable `var' to `value'.
    -w wrapper     Create nbmake script as wrapper.
                   [Default: ${TOOLDIR}/bin/nbmake-${MACHINE}]
    -X x11src      Set X11SRCDIR to x11src.  [Default: /usr/xsrc]
    -x             Set MKX11=yes; build X11 from X11SRCDIR
    -Y extsrcsrc   Set EXTSRCSRCDIR to extsrcsrc.  [Default: /usr/extsrc]
    -y             Set MKEXTSRC=yes; build extsrc from EXTSRCSRCDIR
    -Z var         Unset ("zap") variable `var'.

As can be seen, a number of switches can be set to change the standard build behaviour. A number of them has already been introduced, others can be set as appropriate.

33.7.4. make(1) variables used during build

Several variables control the behaviour of NetBSD builds. Unless otherwise specified, these variables may be set in either the process environment or in the make(1) configuration file specified by MAKECONF. For a definitive list of these options, see BUILDING and share/mk/bsd.README files in the toplevel source directory.


Identifier for the build. The identifier will be appended to object directory names, and can be consulted in the make(1) configuration file in order to set additional build parameters, such as compiler flags.


Directory to contain the built NetBSD system. If set, special options are passed to the compilation tools to prevent their default use of the host system's /usr/include, /usr/lib, and so forth. This pathname should not end with a slash (/) character (For installation into the system's root directory, set DESTDIR to an empty string). The directory must reside on a filesystem which supports long filenames and hard links.

Defaults to an empty string if USETOOLS is yes; unset otherwise. Note: will provide a default (destdir.MACHINE in the top-level .OBJDIR) unless run in expert mode.


If defined by the user, points to the root of an external toolchain (e.g. /usr/local/gnu). This enables the cross-build framework even when default toolchain is not available (see TOOLCHAIN_MISSING below).

Default: Unset


The verbosity of build messages. Supported values:

0 No descriptive messages are shown.
1 Descriptive messages are shown.
2 Descriptive messages are shown (prefixed with a '#') and command output is not suppressed.

Default: 2


Can be set to yes or no. Indicates whether preformatted plaintext manual pages will be created during a build.

Default: yes


Can be set to yes or no. Indicates whether system documentation destined for DESTDIR/usr/share/doc will be installed during a build.

Default: yes


Can be set to yes or no. If set to yes, then for programs intended to be run on the compile host, the name, release and architecture of the host operating system will be suffixed to the name of the object directory created by make obj. This allows for multiple host systems to compile NetBSD for a single target. If set to no, then programs built to be run on the compile host will use the same object directory names as programs built to be run on the target.

Default: no


Can be set to yes or no. Indicates whether GNU info files, used for the documentation of most of the compilation tools, will be created and installed during a build.

Default: yes


Can be set to yes or no. Indicates whether lint(1) will be run against portions of the NetBSD source code during the build, and whether lint libraries will be installed into DESTDIR/usr/libdata/lint

Default: yes


Can be set to yes or no. Indicates whether manual pages will be installed during a build.

Default: yes


Can be set to yes or no. Indicates whether Native Language System locale zone files will be compiled and installed during a build.

Default: yes


Can be set to yes or no. Indicates whether object directories will be created when running make obj. If set to no, then all built files will be located inside the regular source tree.

Default: yes


Can be set to yes or no. Indicates whether shared objects and libraries will be created and installed during a build. If set to no, the entire build will be statically linked.

Default: Platform dependent. As of this writing, all platforms except sh3 default to yes


Can be set to yes or no. Indicates whether the ar(1) format libraries (lib*_pic.a), used to generate shared libraries, are installed during a build.

Default: yes


Can be set to yes or no. Indicates whether profiled libraries (lib*_p.a) will be built and installed during a build.

Default: yes; however, some platforms turn off MKPROFILE by default at times due to toolchain problems with profiled code.


Can be set to yes or no. Indicates whether files destined to reside in DESTDIR/usr/share will be built and installed during a build. If set to no, then all of MKCATPAGES, MKDOC, MKINFO, MKMAN and MKNLS will be set to no unconditionally.

Default: yes


Can be set to yes or no. For X builds, decides if the TrueType bytecode interpreter is turned on. See for details.

Default: no


Can be set to yes or no. Indicates whether an unprivileged install will occur. The user, group, permissions and file flags will not be set on the installed items; instead the information will be appended to a file called METALOG in DESTDIR. The contents of METALOG are used during the generation of the distribution tar files to ensure that the appropriate file ownership is stored.

Default: no


Can be set to yes or no. Indicates whether all install operations intended to write to DESTDIR will compare file timestamps before installing, and skip the install phase if the destination files are up-to-date. This also has implications on full builds (See below).

Default: no


Can be set to yes or no. Indicates whether Clang should be built and installed as the host compiler.

Default: no


Can be set to yes or no. Indicates whether X11 is built from X11SRCDIR.

Default: yes


Directory to hold the host tools, once built. This directory should be unique to a given host system and NetBSD source tree. (However, multiple targets may share the same TOOLDIR; the target-dependent files have unique names). If unset, a default based on the uname(1) information of the host platform will be created in the .OBJDIR of src.

Default: Unset.


Indicates whether the tools specified by TOOLDIR should be used as part of a build in progress. Must be set to yes if cross-compiling.

yes Use the tools from TOOLDIR.
no Do not use the tools from TOOLNAME, but refuse to build native compilation tool components that are version-specific for that tool.
never Do not use the tools from TOOLNAME, even when building native tool components. This is similar to the traditional NetBSD build method, but does not verify that the compilation tools in use are up-to-date enough in order to build the tree successfully. This may cause build or runtime problems when building the whole NetBSD source tree.

Default: yes if building all or part of a whole NetBSD source tree (detected automatically); no otherwise (to preserve traditional semantics of the bsd.*.mk make(1) include files).


Directory containing the X11 source.

Default: usr/xsrc

The following variables only affect the top level Makefile and do not affect manually building subtrees of the NetBSD source code.


Location for the make installworld target to install to.

Default: /


Can be set to yes or no. Indicates whether object directories will be created automatically (via a make obj pass) at the start of a build.

Default: no


Can be set to yes or no. If set, then addition to the effects described for MKUPDATE=yes above, this implies the effect of NOCLEANDIR (i.e., make cleandir is avoided).

Default: no


If set, avoids the make cleandir phase of a full build. This has the effect of allowing only changed files in a source tree to recompiled. This can speed up builds when updating only a few files in the tree.

Default: Unset


If set, avoids the make distrib-dirs of a full build. This skips running mtree(8) on DESTDIR, useful on systems where building as an unprivileged user, or where it is known that the system wide mtree files have not changed.

Default: Unset


If set, avoids the make includes phase of a full build. This has the effect of preventing make(1) from thinking that some programs are out-of-date simply because system include files have changed. However, this option should not be trusted when updating the entire NetBSD source tree arbitrarily; it is suggested to use MKUPDATE=yes in that case.

Default: Unset


If set, specifies the directory to which a release(7) layout will be written at the end of a make release.

Default: Unset


Set to yes on platforms for which there is no working in-tree toolchain, or if you need/wish using native system toolchain (i.e. non-cross tools available via your shell search path).

Default: depends on target platform; on platforms with in-tree toolchain is set to no.