version 1.1, 2013/03/05 23:58:28
|
version 1.2, 2013/03/07 00:16:23
|
Line 1
|
Line 1
|
# Crosscompiling NetBSD with build.sh |
# Crosscompiling NetBSD with build.sh |
|
|
When targeting a product for an embedded platform, it's not feasible to have all |
When targeting a product for an embedded platform, it's not feasible to have all |
the development tools available on that same platform. Instead, some method of |
the development tools available on that same platform. Instead, some method of |
crosscompiling is usually used today. NetBSD 1.6 and forward comes with a |
crosscompiling is usually used today. NetBSD 1.6 and forward comes with a |
framework to build both the operating system's kernel and the whole userland for |
framework to build both the operating system's kernel and the whole userland for |
either the same platform that the compiler runs on, or for a different platform, |
either the same platform that the compiler runs on, or for a different platform, |
using crosscompiling. Crosscompiling requires assembler, linker, compiler etc. |
using crosscompiling. Crosscompiling requires assembler, linker, compiler etc. |
to be available and built for the target platform. The new build scheme will |
to be available and built for the target platform. The new build scheme will |
take care of creating these tools for a given platform, and make them available |
take care of creating these tools for a given platform, and make them available |
ready to use to do development work. |
ready to use to do development work. |
|
|
In this chapter, we will show how to use `build.sh` to first create a |
In this chapter, we will show how to use `build.sh` to first create a |
crosscompiling toolchain, including cross-compiler, cross-assembler, |
crosscompiling toolchain, including cross-compiler, cross-assembler, |
cross-linker and so on. While native kernel builds are covered in [[Compiling |
cross-linker and so on. While native kernel builds are covered in [[Compiling |
the kernel|guide/kernel]], these tools are then used to manually configure and |
the kernel|guide/kernel]], these tools are then used to manually configure and |
crosscompile a kernel for a different platform, and then show how to use |
crosscompile a kernel for a different platform, and then show how to use |
`build.sh` as a convenient alternative. After that works, the whole NetBSD |
`build.sh` as a convenient alternative. After that works, the whole NetBSD |
userland will be compiled and packed up in the format of a NetBSD release. In |
userland will be compiled and packed up in the format of a NetBSD release. In |
the examples, we will use the Sun UltraSPARC (*sparc64*) 64-bit platform as |
the examples, we will use the Sun UltraSPARC (*sparc64*) 64-bit platform as |
target platform, any other platform supported by NetBSD can be targetted as well |
target platform, any other platform supported by NetBSD can be targetted as well |
specifying its name (see `/usr/src/sys/arch`). |
specifying its name (see `/usr/src/sys/arch`). |
|
|
Before starting, take note that it is assumed that the NetBSD sources from the |
Before starting, take note that it is assumed that the NetBSD sources from the |
`netbsd-4-0` branch are available in `/usr/src` as described in |
`netbsd-4-0` branch are available in `/usr/src` as described in |
[[Obtaining the sources|guide/fetch]]. |
[[Obtaining the sources|guide/fetch]]. |
|
|
A more detailed description of the `build.sh` framework can be found in Luke |
A more detailed description of the `build.sh` framework can be found in Luke |
Mewburn and Matthew Green's |
Mewburn and Matthew Green's |
[paper](http://www.mewburn.net/luke/papers/build.sh.pdf) and their |
[paper](http://www.mewburn.net/luke/papers/build.sh.pdf) and their |
[presentation](http://www.mewburn.net/luke/talks/bsdcon-2003/index.html) from |
[presentation](http://www.mewburn.net/luke/talks/bsdcon-2003/index.html) from |
BSDCon 2003 as well as in `/usr/src/BUILDING`. |
BSDCon 2003 as well as in `/usr/src/BUILDING`. |
|
|
## Building the crosscompiler |
## Building the crosscompiler |
|
|
The first step to do cross-development is to get all the necessary tools |
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 |
available. In NetBSD terminology, this is called the "toolchain", and it |
includes BSD-compatible |
includes BSD-compatible |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current), |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-current), |
C/C++ compilers, linker, assembler, |
C/C++ compilers, linker, assembler, |
[config(8)](http://netbsd.gw.com/cgi-bin/man-cgi?config+8+NetBSD-current), |
[config(8)](http://netbsd.gw.com/cgi-bin/man-cgi?config+8+NetBSD-current), |
as well as a fair number of tools that are only required when crosscompiling a |
as well as a fair number of tools that are only required when crosscompiling a |
full NetBSD release, which we won't cover here. |
full NetBSD release, which we won't cover here. |
|
|
The command to create the crosscompiler is quite simple, using NetBSD's new |
The command to create the crosscompiler is quite simple, using NetBSD's new |
`src/build.sh` script. Please note that all the commands here can be run as |
`src/build.sh` script. Please note that all the commands here can be run as |
normal (non-root) user: |
normal (non-root) user: |
|
|
$ cd /usr/src |
$ cd /usr/src |
$ ./build.sh -m sparc64 tools |
$ ./build.sh -m sparc64 tools |
|
|
Make sure that the directory `/usr/obj` does exist, or add a `-O` option to the |
Make sure that the directory `/usr/obj` does exist, or add a `-O` option to the |
build.sh call, redirecting the object directory someplace else. |
build.sh call, redirecting the object directory someplace else. |
|
|
If the tools have been built previously and they only need updated, then the |
If the tools have been built previously and they only need updated, then the |
update option `-u` can be used to only rebuild tools that have changed: |
update option `-u` can be used to only rebuild tools that have changed: |
|
|
$ ./build.sh -u -m sparc64 tools |
$ ./build.sh -u -m sparc64 tools |
|
|
When the tools are built, information about them and several environment |
When the tools are built, information about them and several environment |
variables is printed out: |
variables is printed out: |
|
|
... |
... |
Line 79 variables is printed out:
|
Line 79 variables is printed out:
|
Tools built to /usr/src/tooldir.NetBSD-4.0-i386 |
Tools built to /usr/src/tooldir.NetBSD-4.0-i386 |
build.sh started: Thu Dec 2 22:18:11 CET 2007 |
build.sh started: Thu Dec 2 22:18:11 CET 2007 |
build.sh ended: Thu Dec 2 22:28:22 CET 2007 |
build.sh ended: Thu Dec 2 22:28:22 CET 2007 |
===> . |
===> . |
|
|
During the build, object directories are used consistently, i.e. special |
During the build, object directories are used consistently, i.e. special |
directories are kept that keep the platform-specific object files and compile |
directories are kept that keep the platform-specific object files and compile |
results. In our example, they will be kept in directories named `obj.sparc64` as |
results. In our example, they will be kept in directories named `obj.sparc64` as |
we build for UltraSPARC as target platform. |
we build for UltraSPARC as target platform. |
|
|
The toolchain itself is part of this, but as it's hosted and compiled for a i386 |
The toolchain itself is part of this, but as it's hosted and compiled for a i386 |
system, it will get placed in its own directory indicating where to cross-build |
system, it will get placed in its own directory indicating where to cross-build |
from. Here's where our crosscompiler tools are located: |
from. Here's where our crosscompiler tools are located: |
|
|
$ pwd |
$ pwd |
Line 95 from. Here's where our crosscompiler too
|
Line 95 from. Here's where our crosscompiler too
|
$ ls -d tooldir.* |
$ ls -d tooldir.* |
tooldir.NetBSD-4.0-i386 |
tooldir.NetBSD-4.0-i386 |
|
|
So the general rule of thumb is for a given `host` and `target` system |
So the general rule of thumb is for a given `host` and `target` system |
combination, the crosscompiler will be placed in the `src/tooldir.host` |
combination, the crosscompiler will be placed in the `src/tooldir.host` |
directory by default. A full list of all tools created for crosscompiling the |
directory by default. A full list of all tools created for crosscompiling the |
whole NetBSD operating system includes: |
whole NetBSD operating system includes: |
|
|
$ ls tooldir.NetBSD-4.0-i386/bin/ |
$ ls tooldir.NetBSD-4.0-i386/bin/ |
Line 127 whole NetBSD operating system includes:
|
Line 127 whole NetBSD operating system includes:
|
nblorder nbtexindex sparc64--netbsd-strings |
nblorder nbtexindex sparc64--netbsd-strings |
nbm4 nbtsort sparc64--netbsd-strip |
nbm4 nbtsort sparc64--netbsd-strip |
nbmake nbuudecode |
nbmake nbuudecode |
nbmake-sparc64 nbyacc |
nbmake-sparc64 nbyacc |
|
|
As you can see, most of the tools that are available native on NetBSD are |
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 |
present with some program prefix to identify the target platform for tools that |
are specific to a certain target platform. |
are specific to a certain target platform. |
|
|
One important tool that should be pointed out here is `nbmake-sparc64`. This is |
One important tool that should be pointed out here is `nbmake-sparc64`. This is |
a shell wrapper for a BSD compatible |
a shell wrapper for a BSD compatible |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) command |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) command |
that's setup to use all the right commands from the crosscompiler toolchain. |
that's setup to use all the right commands from the crosscompiler toolchain. |
Using this wrapper instead of `/usr/bin/make` allows crosscompiling programs |
Using this wrapper instead of `/usr/bin/make` allows crosscompiling programs |
that were written using the NetBSD Makefile infrastructure (see `src/share/mk`). |
that were written using the NetBSD Makefile infrastructure (see `src/share/mk`). |
We will use this |
We will use this |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) wrapper |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) wrapper |
in a second to cross compile the kernel! |
in a second to cross compile the kernel! |
|
|
## Configuring the kernel manually |
## Configuring the kernel manually |
|
|
Now that we have a working crosscompiler available, the "usual" steps for |
Now that we have a working crosscompiler available, the "usual" steps for |
building a kernel are needed - create a kernel config file, run |
building a kernel are needed - create a kernel config file, run |
[config(1)](http://netbsd.gw.com/cgi-bin/man-cgi?config+1+NetBSD-5.0.1+i386), |
[config(1)](http://netbsd.gw.com/cgi-bin/man-cgi?config+1+NetBSD-5.0.1+i386), |
then build. As the |
then build. As the |
[config(1)](http://netbsd.gw.com/cgi-bin/man-cgi?config+1+NetBSD-5.0.1+i386) |
[config(1)](http://netbsd.gw.com/cgi-bin/man-cgi?config+1+NetBSD-5.0.1+i386) |
program used to create header files and Makefile for a kernel build is platform |
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 |
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 |
toolchain. That aside, the procedure is just as like compiling a "native" NetBSD |
kernel. Commands involved here are: |
kernel. Commands involved here are: |
|
|
$ cd /usr/src/sys/arch/sparc64/conf |
$ cd /usr/src/sys/arch/sparc64/conf |
Line 160 kernel. Commands involved here are:
|
Line 160 kernel. Commands involved here are:
|
$ vi MYKERNEL |
$ vi MYKERNEL |
$ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbconfig MYKERNEL |
$ /usr/src/tooldir.NetBSD-4.0-i386/bin/nbconfig MYKERNEL |
|
|
That's all. This command has created a directory `../compile/MYKERNEL` with a |
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 |
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, |
kernel, a Makefile that is setup to build all the needed files for the kernel, |
and link them together. |
and link them together. |
|
|
## Crosscompiling the kernel manually |
## Crosscompiling the kernel manually |
|
|
We have all the files and tools available to crosscompile our UltraSPARC-based |
We have all the files and tools available to crosscompile our UltraSPARC-based |
kernel from our Intel-based host system, so let's get to it! After changing in |
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 crosscompiler |
the directory created in the previous step, we need to use the crosscompiler |
toolchain's `nbmake-sparc64` shell wrapper, which just calls make(1) with all |
toolchain's `nbmake-sparc64` shell wrapper, which just calls make(1) with all |
the necessary settings for crosscompiling for a sparc64 platform: |
the necessary settings for crosscompiling for a sparc64 platform: |
|
|
$ cd ../compile/MYKERNEL/ |
$ cd ../compile/MYKERNEL/ |
Line 185 This will churn away a bit, then spit ou
|
Line 185 This will churn away a bit, then spit ou
|
$ ls -l netbsd |
$ ls -l netbsd |
-rwxr-xr-x 1 feyrer 666 5874663 Dec 2 23:17 netbsd |
-rwxr-xr-x 1 feyrer 666 5874663 Dec 2 23:17 netbsd |
$ file netbsd |
$ file netbsd |
netbsd: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), statically linked, not stripped |
netbsd: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), statically linked, not stripped |
|
|
Now the kernel in the file `netbsd` can either be transferred to a UltraSPARC |
Now the kernel in the file `netbsd` can either be transferred to a UltraSPARC |
machine (via NFS, FTP, scp, etc.) and booted from a possible harddisk, or |
machine (via NFS, FTP, scp, etc.) and booted from a possible harddisk, or |
directly from our cross-development machine using NFS. |
directly from our cross-development machine using NFS. |
|
|
After configuring and crosscompiling the kernel, the next logical step is to |
After configuring and crosscompiling the kernel, the next logical step is to |
crosscompile the whole system, and bring it into a distribution-ready format. |
crosscompile the whole system, and bring it into a distribution-ready format. |
Before doing so, an alternative approach to crosscompiling a kernel will be |
Before doing so, an alternative approach to crosscompiling a kernel will be |
shown in the next section, using the `build.sh` script to do configuration and |
shown in the next section, using the `build.sh` script to do configuration and |
crosscompilation of the kernel in one step. |
crosscompilation of the kernel in one step. |
|
|
## Crosscompiling the kernel with build.sh |
## Crosscompiling the kernel with build.sh |
|
|
A cross compiled kernel can be done manually as described in the previous |
A cross compiled kernel can be done manually as described in the previous |
sections, or by the easier method of using `build.sh`, which will be shown here. |
sections, or by the easier method of using `build.sh`, which will be shown here. |
|
|
Preparation of the kernel config file is the same as described above: |
Preparation of the kernel config file is the same as described above: |
|
|
$ cd /usr/src/sys/arch/sparc64/conf |
$ cd /usr/src/sys/arch/sparc64/conf |
$ cp GENERIC MYKERNEL |
$ cp GENERIC MYKERNEL |
$ vi MYKERNEL |
$ vi MYKERNEL |
|
|
Then edit `MYKERNEL` and once finished, all that needs to be done is to use |
Then edit `MYKERNEL` and once finished, all that needs to be done is to use |
`build.sh` to build the kernel (it will also configure it, running the steps |
`build.sh` to build the kernel (it will also configure it, running the steps |
shown above): |
shown above): |
|
|
$ cd /usr/src |
$ cd /usr/src |
$ ./build.sh -u -m sparc64 kernel=MYKERNEL |
$ ./build.sh -u -m sparc64 kernel=MYKERNEL |
|
|
Notice that update (`-u`) was specified, the tools are already built, there is |
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, `build.sh` will |
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: |
print out the location of it along with other information: |
|
|
... |
... |
Line 240 print out the location of it along with
|
Line 240 print out the location of it along with
|
/usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd |
/usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd |
build.sh started: Thu Dec 2 23:30:02 CET 2007 |
build.sh started: Thu Dec 2 23:30:02 CET 2007 |
build.sh ended: Thu Dec 2 23:38:22 CET 2007 |
build.sh ended: Thu Dec 2 23:38:22 CET 2007 |
===> . |
===> . |
|
|
The path to the kernel built is of interest here: |
The path to the kernel built is of interest here: |
`/usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd`, it can be used |
`/usr/src/sys/arch/sparc64/compile/obj.sparc64/MYKERNEL/netbsd`, it can be used |
the same way as described above. |
the same way as described above. |
|
|
## Crosscompiling the userland |
## Crosscompiling the userland |
|
|
By now it is probably becoming clear that the toolchain actually works in |
By now it is probably becoming clear that the toolchain actually works in |
stages. First the crosscompiler is built, then a kernel. Since `build.sh` will |
stages. First the crosscompiler is built, then a kernel. Since `build.sh` will |
attempt to rebuild the tools at every invocation, using `update` saves time. It |
attempt to rebuild the tools at every invocation, using `update` saves time. It |
is probably also clear that outside of a few options, the `build.sh` semantics |
is probably also clear that outside of a few options, the `build.sh` semantics |
are basically `build.sh command`. So, it stands to reason that building the |
are basically `build.sh command`. So, it stands to reason that building the |
whole userland and/or a release is a matter of using the right commands. |
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 |
It should be no surprise that building and creating a release would look like |
the following: |
the following: |
|
|
$ ./build.sh -U -u -m sparc64 release |
$ ./build.sh -U -u -m sparc64 release |
|
|
These commands will compile the full NetBSD userland and put it into a |
These commands will compile the full NetBSD userland and put it into a |
destination directory, and then build a release from it in a release directory. |
destination directory, and then build a release from it in a release directory. |
The `-U` switch is added here for an *unprivileged* build, i.e. one that's |
The `-U` switch is added here for an *unprivileged* build, i.e. one that's |
running as normal user and not as root. As no further switches to `build.sh` |
running as normal user and not as root. As no further switches to `build.sh` |
were given nor any environment variables were set, the defaults of |
were given nor any environment variables were set, the defaults of |
`DESTDIR=/usr/src/destdir.sparc64` and `RELEASEDIR=/usr/src/releasedir` are |
`DESTDIR=/usr/src/destdir.sparc64` and `RELEASEDIR=/usr/src/releasedir` are |
used, as shown in the `build.sh`-output above. |
used, as shown in the `build.sh`-output above. |
|
|
## Crosscompiling the X Window System |
## Crosscompiling the X Window System |
|
|
The NetBSD project has its own copy of the X Window System's source which is |
The NetBSD project has its own copy of the X Window System's source which is |
currently based on XFree86 version 4, and which contains changes to make X going |
currently based on XFree86 version 4, and which contains changes to make X going |
on as many of the platforms supported by NetBSD as possible. Due to this, it is |
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, |
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, |
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 `/usr/xsrc` just as src |
the xsrc sources must be checked out from CVS into `/usr/xsrc` just as src |
and pkgsrc were as described in [[Obtaining the sources|guide/fetch]]. |
and pkgsrc were as described in [[Obtaining the sources|guide/fetch]]. |
|
|
After this, X can be crosscompiled for the target platform by adding the `-x` |
After this, X can be crosscompiled for the target platform by adding the `-x` |
switch to build.sh, e.g. when creating a full release: |
switch to build.sh, e.g. when creating a full release: |
|
|
$ ./build.sh -U -x -u -m sparc64 release |
$ ./build.sh -U -x -u -m sparc64 release |
|
|
The `-U` flag for doing unprivileged (non-root) builds and the `-u` flag for not |
The `-U` flag for doing unprivileged (non-root) builds and the `-u` flag for not |
removing old files before building as well as the `-m arch` option to define the |
removing old files before building as well as the `-m arch` option to define the |
target architecture have already been introduced, and the `-x` option to also |
target architecture have already been introduced, and the `-x` option to also |
(cross)compile xsrc is another option. |
(cross)compile xsrc is another option. |
|
|
## Changing build behaviour |
## Changing build behaviour |
|
|
Similar to the old, manual building method, the new toolchain has a lot of |
Similar to the old, manual building method, the new toolchain has a lot of |
variables that can be used to direct things like where certain files go, what |
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. |
(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 |
In this section some examples of changing default settings are given, each |
following its own ways. |
following its own ways. |
|
|
### Changing the Destination Directory |
### Changing the Destination Directory |
|
|
Many people like to track NetBSD-current and perform cross compiles of |
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 |
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 |
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 |
track of changes and building every now and again, one can be assured that these |
architectures can build their own release. |
architectures can build their own release. |
|
|
It is reasonable to assume that if one is tracking and building for more than |
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 |
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 |
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 |
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). |
the same way as any other variable (depending on your shell of course). |
|
|
For bash, the Bourne or Korn shell, this is: |
For bash, the Bourne or Korn shell, this is: |
Line 318 For tcsh and the C shell, the command is
|
Line 318 For tcsh and the C shell, the command is
|
|
|
$ setenv DESTDIR /usr/builds/sparc64 |
$ setenv DESTDIR /usr/builds/sparc64 |
|
|
Simple enough. When the build is run, the binaries and files will be sent to |
Simple enough. When the build is run, the binaries and files will be sent to |
`/usr/builds`. |
`/usr/builds`. |
|
|
### Static Builds |
### Static Builds |
|
|
The NetBSD toolchain builds and links against shared libraries by default. Many |
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 |
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 |
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 |
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 |
environment variable set in a particular way, then it is easiest to simply add |
the changed setting to `/etc/mk.conf`. |
the changed setting to `/etc/mk.conf`. |
|
|
To make sure a build box always builds statically, simply add the following line |
To make sure a build box always builds statically, simply add the following line |
to `/etc/mk.conf`: |
to `/etc/mk.conf`: |
|
|
LDSTATIC=-static |
LDSTATIC=-static |
|
|
### Using build.sh options |
### Using build.sh options |
|
|
Besides variables in environment and `/etc/mk.conf`, the build process can be |
Besides variables in environment and `/etc/mk.conf`, the build process can be |
influenced by a number of switches to the `build.sh` script itself, as we have |
influenced by a number of switches to the `build.sh` script itself, as we have |
already seen when forcing unprivileged (non-root) builds, selecting the target |
already seen when forcing unprivileged (non-root) builds, selecting the target |
architecture or preventing deletion of old files before the build. All these |
architecture or preventing deletion of old files before the build. All these |
options can be listed by running `build.sh -h`: |
options can be listed by running `build.sh -h`: |
|
|
$ cd /usr/src |
$ cd /usr/src |
Line 402 options can be listed by running `build.
|
Line 402 options can be listed by running `build.
|
[Default: ${TOOLDIR}/bin/nbmake-${MACHINE}] |
[Default: ${TOOLDIR}/bin/nbmake-${MACHINE}] |
-X x11src Set X11SRCDIR to x11src. [Default: /usr/xsrc] |
-X x11src Set X11SRCDIR to x11src. [Default: /usr/xsrc] |
-x Set MKX11=yes; build X11R6 from X11SRCDIR |
-x Set MKX11=yes; build X11R6 from X11SRCDIR |
-Z v Unset ("zap") variable `v'. |
-Z v Unset ("zap") variable `v'. |
|
|
As can be seen, a number of switches can be set to change the standard build |
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 |
behaviour. A number of them has already been introduced, others can be set as |
appropriate. |
appropriate. |
|
|
### make(1) variables used during build |
### make(1) variables used during build |
|
|
Several variables control the behaviour of NetBSD builds. Unless otherwise |
Several variables control the behaviour of NetBSD builds. Unless otherwise |
specified, these variables may be set in either the process environment or in |
specified, these variables may be set in either the process environment or in |
the [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) |
the [make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) |
configuration file specified by `MAKECONF`. For a definitive list of these |
configuration file specified by `MAKECONF`. For a definitive list of these |
options, see `BUILDING` and `share/mk/bsd.README` files in the toplevel source |
options, see `BUILDING` and `share/mk/bsd.README` files in the toplevel source |
directory. |
directory. |
|
|
* *BUILDID* -- Identifier for the build. The identifier will be appended to |
* *BUILDID* -- Identifier for the build. The identifier will be appended to |
object directory names, and can be consulted in the |
object directory names, and can be consulted in the |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) |
configuration file in order to set additional build parameters, such as |
configuration file in order to set additional build parameters, such as |
compiler flags. |
compiler flags. |
|
|
* *DESTDIR* -- Directory to contain the built NetBSD system. If set, special |
* *DESTDIR* -- Directory to contain the built NetBSD system. If set, special |
options are passed to the compilation tools to prevent their default use of |
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 |
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 |
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 |
root directory, set `DESTDIR` to an empty string). The directory must reside |
on a filesystem which supports long filenames and hard links. |
on a filesystem which supports long filenames and hard links. |
|
|
Defaults to an empty string if `USETOOLS` is `yes`; unset otherwise. Note: |
Defaults to an empty string if `USETOOLS` is `yes`; unset otherwise. Note: |
`build.sh` will provide a default (destdir.MACHINE in the top-level |
`build.sh` will provide a default (destdir.MACHINE in the top-level |
`.OBJDIR`) unless run in `expert` mode. |
`.OBJDIR`) unless run in `expert` mode. |
|
|
* *EXTERNAL\_TOOLCHAIN* -- If defined by the user, points to the root of an |
* *EXTERNAL\_TOOLCHAIN* -- If defined by the user, points to the root of an |
external toolchain (e.g. `/usr/local/gnu`). This enables the cross-build |
external toolchain (e.g. `/usr/local/gnu`). This enables the cross-build |
framework even when default toolchain is not available (see |
framework even when default toolchain is not available (see |
`TOOLCHAIN_MISSING` below). |
`TOOLCHAIN_MISSING` below). |
|
|
Default: Unset |
Default: Unset |
Line 445 directory.
|
Line 445 directory.
|
|
|
* `0` -- No descriptive messages are shown. |
* `0` -- No descriptive messages are shown. |
* `1` -- Descriptive messages are shown. |
* `1` -- Descriptive messages are shown. |
* `2` -- Descriptive messages are shown (prefixed with a '\#') and command |
* `2` -- Descriptive messages are shown (prefixed with a '\#') and command |
output is not suppressed. |
output is not suppressed. |
|
|
Default: 2 |
Default: 2 |
|
|
* *MKCATPAGES* -- Can be set to `yes` or `no`. Indicates whether preformatted |
* *MKCATPAGES* -- Can be set to `yes` or `no`. Indicates whether preformatted |
plaintext manual pages will be created during a build. |
plaintext manual pages will be created during a build. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKCRYPTO* -- Can be set to `yes` or `no`. Indicates whether cryptographic |
* *MKCRYPTO* -- Can be set to `yes` or `no`. Indicates whether cryptographic |
code will be included in a build; provided for the benefit of countries that |
code will be included in a build; provided for the benefit of countries that |
do not allow strong cryptography. Will not affect the standard low-security |
do not allow strong cryptography. Will not affect the standard low-security |
password encryption system, |
password encryption system, |
[crypt(3)](http://netbsd.gw.com/cgi-bin/man-cgi?crypt+3+NetBSD-5.0.1+i386). |
[crypt(3)](http://netbsd.gw.com/cgi-bin/man-cgi?crypt+3+NetBSD-5.0.1+i386). |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKDOC* -- Can be set to `yes` or `no`. Indicates whether system |
* *MKDOC* -- Can be set to `yes` or `no`. Indicates whether system |
documentation destined for `DESTDIR``/usr/share/doc` will be installed during |
documentation destined for `DESTDIR``/usr/share/doc` will be installed during |
a build. |
a build. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKHOSTOBJ* -- Can be set to `yes` or `no`. If set to `yes`, then for |
* *MKHOSTOBJ* -- 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 |
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 |
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 |
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 |
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 |
be run on the compile host will use the same object directory names as |
programs built to be run on the target. |
programs built to be run on the target. |
|
|
Default: `no` |
Default: `no` |
|
|
* *MKINFO* -- Can be set to `yes` or `no`. Indicates whether GNU info files, |
* *MKINFO* -- 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 |
used for the documentation of most of the compilation tools, will be created |
and installed during a build. |
and installed during a build. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKLINT* -- Can be set to `yes` or `no`. Indicates whether |
* *MKLINT* -- Can be set to `yes` or `no`. Indicates whether |
[lint(1)](http://netbsd.gw.com/cgi-bin/man-cgi?lint+1+NetBSD-5.0.1+i386) will |
[lint(1)](http://netbsd.gw.com/cgi-bin/man-cgi?lint+1+NetBSD-5.0.1+i386) will |
be run against portions of the NetBSD source code during the build, and |
be run against portions of the NetBSD source code during the build, and |
whether lint libraries will be installed into `DESTDIR``/usr/libdata/lint` |
whether lint libraries will be installed into `DESTDIR``/usr/libdata/lint` |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKMAN* -- Can be set to `yes` or `no`. Indicates whether manual pages will |
* *MKMAN* -- Can be set to `yes` or `no`. Indicates whether manual pages will |
be installed during a build. |
be installed during a build. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKNLS* -- Can be set to `yes` or `no`. Indicates whether Native Language |
* *MKNLS* -- Can be set to `yes` or `no`. Indicates whether Native Language |
System locale zone files will be compiled and installed during a build. |
System locale zone files will be compiled and installed during a build. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKOBJ* -- Can be set to `yes` or `no`. Indicates whether object directories |
* *MKOBJ* -- 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 created when running `make obj`. If set to `no`, then all built files |
will be located inside the regular source tree. |
will be located inside the regular source tree. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKPIC* -- Can be set to `yes` or `no`. Indicates whether shared objects and |
* *MKPIC* -- 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 |
libraries will be created and installed during a build. If set to `no`, the |
entire build will be statically linked. |
entire build will be statically linked. |
|
|
Default: Platform dependent. As of this writing, all platforms except sh3 default to `yes` |
Default: Platform dependent. As of this writing, all platforms except sh3 default to `yes` |
|
|
* *MKPICINSTALL* -- Can be set to `yes` or `no`. Indicates whether the |
* *MKPICINSTALL* -- Can be set to `yes` or `no`. Indicates whether the |
[ar(1)](http://netbsd.gw.com/cgi-bin/man-cgi?ar+1+NetBSD-5.0.1+i386) format |
[ar(1)](http://netbsd.gw.com/cgi-bin/man-cgi?ar+1+NetBSD-5.0.1+i386) format |
libraries (`lib*_pic.a`), used to generate shared libraries, are installed |
libraries (`lib*_pic.a`), used to generate shared libraries, are installed |
during a build. |
during a build. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKPROFILE* -- Can be set to `yes` or `no`. Indicates whether profiled |
* *MKPROFILE* -- Can be set to `yes` or `no`. Indicates whether profiled |
libraries (`lib*_p.a`) will be built and installed during a build. |
libraries (`lib*_p.a`) will be built and installed during a build. |
|
|
Default: `yes`; however, some platforms turn off `MKPROFILE` by default at |
Default: `yes`; however, some platforms turn off `MKPROFILE` by default at |
times due to toolchain problems with profiled code. |
times due to toolchain problems with profiled code. |
|
|
* *MKSHARE* -- Can be set to `yes` or `no`. Indicates whether files destined to |
* *MKSHARE* -- 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. |
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 |
If set to `no`, then all of `MKCATPAGES`, `MKDOC`, `MKINFO`, `MKMAN` and |
`MKNLS` will be set to `no` unconditionally. |
`MKNLS` will be set to `no` unconditionally. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *MKTTINTERP* -- Can be set to `yes` or `no`. For X builds, decides if the |
* *MKTTINTERP* -- Can be set to `yes` or `no`. For X builds, decides if the |
TrueType bytecode interpreter is turned on. See |
TrueType bytecode interpreter is turned on. See |
[freetype.org](http://freetype.org/patents.html) for details. |
[freetype.org](http://freetype.org/patents.html) for details. |
|
|
Default: `no` |
Default: `no` |
|
|
* *MKUNPRIVED* -- Can be set to `yes` or `no`. Indicates whether an |
* *MKUNPRIVED* -- Can be set to `yes` or `no`. Indicates whether an |
unprivileged install will occur. The user, group, permissions and file flags |
unprivileged install will occur. The user, group, permissions and file flags |
will not be set on the installed items; instead the information will be |
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` |
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 |
are used during the generation of the distribution tar files to ensure that |
the appropriate file ownership is stored. |
the appropriate file ownership is stored. |
|
|
Default: `no` |
Default: `no` |
|
|
* *MKUPDATE* -- Can be set to `yes` or `no`. Indicates whether all install |
* *MKUPDATE* -- Can be set to `yes` or `no`. Indicates whether all install |
operations intended to write to `DESTDIR` will compare file timestamps before |
operations intended to write to `DESTDIR` will compare file timestamps before |
installing, and skip the install phase if the destination files are |
installing, and skip the install phase if the destination files are |
up-to-date. This also has implications on full builds (See below). |
up-to-date. This also has implications on full builds (See below). |
|
|
Default: `no` |
Default: `no` |
|
|
* *MKX11* -- Can be set to `yes` or `no`. Indicates whether X11R6 is built from |
* *MKX11* -- Can be set to `yes` or `no`. Indicates whether X11R6 is built from |
`X11SRCDIR`. |
`X11SRCDIR`. |
|
|
Default: `yes` |
Default: `yes` |
|
|
* *TOOLDIR* -- Directory to hold the host tools, once built. This directory |
* *TOOLDIR* -- Directory to hold the host tools, once built. This directory |
should be unique to a given host system and NetBSD source tree. (However, |
should be unique to a given host system and NetBSD source tree. (However, |
multiple targets may share the same `TOOLDIR`; the target-dependent files |
multiple targets may share the same `TOOLDIR`; the target-dependent files |
have unique names). If unset, a default based on the |
have unique names). If unset, a default based on the |
[uname(1)](http://netbsd.gw.com/cgi-bin/man-cgi?uname+1+NetBSD-5.0.1+i386) |
[uname(1)](http://netbsd.gw.com/cgi-bin/man-cgi?uname+1+NetBSD-5.0.1+i386) |
information of the host platform will be created in the `.OBJDIR` of `src`. |
information of the host platform will be created in the `.OBJDIR` of `src`. |
|
|
Default: Unset. |
Default: Unset. |
|
|
* *USETOOLS* -- Indicates whether the tools specified by `TOOLDIR` should be |
* *USETOOLS* -- 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. |
used as part of a build in progress. Must be set to `yes` if cross-compiling. |
|
|
* `yes` -- Use the tools from `TOOLDIR`. |
* `yes` -- Use the tools from `TOOLDIR`. |
* `no` -- Do not use the tools from `TOOLNAME`, but refuse to build native |
* `no` -- Do not use the tools from `TOOLNAME`, but refuse to build native |
compilation tool components that are version-specific for that tool. |
compilation tool components that are version-specific for that tool. |
* `never` -- Do not use the tools from `TOOLNAME`, even when building native |
* `never` -- Do not use the tools from `TOOLNAME`, even when building native |
tool components. This is similar to the traditional NetBSD build method, |
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 |
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 |
enough in order to build the tree successfully. This may cause build or |
runtime problems when building the whole NetBSD source tree. |
runtime problems when building the whole NetBSD source tree. |
|
|
Default: `yes` if building all or part of a 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 |
(detected automatically); `no` otherwise (to preserve traditional semantics |
of the `bsd.*.mk` |
of the `bsd.*.mk` |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) |
include files). |
include files). |
|
|
* *X11SRCDIR* -- Directory containing the X11R6 source. The main X11R6 source |
* *X11SRCDIR* -- Directory containing the X11R6 source. The main X11R6 source |
is found in `X11SRCDIR/xfree/xc`. |
is found in `X11SRCDIR/xfree/xc`. |
|
|
Default: `usr/xsrc` |
Default: `usr/xsrc` |
|
|
The following variables only affect the top level `Makefile` and do not affect |
The following variables only affect the top level `Makefile` and do not affect |
manually building subtrees of the NetBSD source code. |
manually building subtrees of the NetBSD source code. |
|
|
* *INSTALLWORLDDIR* -- Location for the `make installworld` target to install |
* *INSTALLWORLDDIR* -- Location for the `make installworld` target to install |
to. |
to. |
|
|
Default: `/` |
Default: `/` |
|
|
* *MKOBJDIRS* -- Can be set to `yes` or `no`. Indicates whether object |
* *MKOBJDIRS* -- Can be set to `yes` or `no`. Indicates whether object |
directories will be created automatically (via a `make obj` pass) at the |
directories will be created automatically (via a `make obj` pass) at the |
start of a build. |
start of a build. |
|
|
Default: `no` |
Default: `no` |
|
|
* *MKUPDATE* -- Can be set to `yes` or `no`. If set, then addition to the |
* *MKUPDATE* -- Can be set to `yes` or `no`. If set, then addition to the |
effects described for `MKUPDATE=yes` above, this implies the effect of |
effects described for `MKUPDATE=yes` above, this implies the effect of |
`NOCLEANDIR` (i.e., `make cleandir` is avoided). |
`NOCLEANDIR` (i.e., `make cleandir` is avoided). |
|
|
Default: `no` |
Default: `no` |
|
|
* *NOCLEANDIR* -- If set, avoids the `make cleandir` phase of a full build. |
* *NOCLEANDIR* -- 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 |
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 |
recompiled. This can speed up builds when updating only a few files in the |
tree. |
tree. |
|
|
Default: Unset |
Default: Unset |
|
|
* *NODISTRIBDIRS* -- If set, avoids the `make distrib-dirs` of a full build. |
* *NODISTRIBDIRS* -- If set, avoids the `make distrib-dirs` of a full build. |
This skips running |
This skips running |
[mtree(8)](http://netbsd.gw.com/cgi-bin/man-cgi?mtree+8+NetBSD-5.0.1+i386) on |
[mtree(8)](http://netbsd.gw.com/cgi-bin/man-cgi?mtree+8+NetBSD-5.0.1+i386) on |
`DESTDIR`, useful on systems where building as an unprivileged user, or where |
`DESTDIR`, useful on systems where building as an unprivileged user, or where |
it is known that the system wide mtree files have not changed. |
it is known that the system wide mtree files have not changed. |
|
|
Default: Unset |
Default: Unset |
|
|
* *NOINCLUDES* -- If set, avoids the `make includes` phase of a full build. |
* *NOINCLUDES* -- If set, avoids the `make includes` phase of a full build. |
This has the effect of preventing |
This has the effect of preventing |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) from |
[make(1)](http://netbsd.gw.com/cgi-bin/man-cgi?make+1+NetBSD-5.0.1+i386) from |
thinking that some programs are out-of-date simply because system include |
thinking that some programs are out-of-date simply because system include |
files have changed. However, this option should not be trusted when updating |
files have changed. However, this option should not be trusted when updating |
the entire NetBSD source tree arbitrarily; it is suggested to use |
the entire NetBSD source tree arbitrarily; it is suggested to use |
`MKUPDATE=yes` in that case. |
`MKUPDATE=yes` in that case. |
|
|
Default: Unset |
Default: Unset |
|
|
* *RELEASEDIR* -- If set, specifies the directory to which a |
* *RELEASEDIR* -- If set, specifies the directory to which a |
[release(7)](http://netbsd.gw.com/cgi-bin/man-cgi?release+7+NetBSD-5.0.1+i386) |
[release(7)](http://netbsd.gw.com/cgi-bin/man-cgi?release+7+NetBSD-5.0.1+i386) |
layout will be written at the end of a `make release`. |
layout will be written at the end of a `make release`. |
|
|
Default: Unset |
Default: Unset |
|
|
* *TOOLCHAIN\_MISSING* -- Set to `yes` on platforms for which there is no |
* *TOOLCHAIN\_MISSING* -- Set to `yes` on platforms for which there is no |
working in-tree toolchain, or if you need/wish using native system toolchain |
working in-tree toolchain, or if you need/wish using native system toolchain |
(i.e. non-cross tools available via your shell search path). |
(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`. |
Default: depends on target platform; on platforms with in-tree toolchain is set to `no`. |