this is obsolete doc -- see http://doc.nethence.com/ instead

NetBSD compilation tutorial 

 

Introduction 

There are basically the three questions you need to answer before you go further. The methods are quite different depending on what you want. 

- Do you want to compile the kernel or the whole system? 

- Do you want to compile it on a NetBSD system or another Unix? 

- If running a NetBSD system, do you want to build binaries for the same hardware architecture ? (cross-compiling with -m) 

- If running a NetBSD system, are you willing to compile a kernel or system that is more recent than the currently running one? 

With the last three points combined, say running netbsd, building same major release and for the same arch, you can skip the building of tools, which makes you same a reasonable amount of time. 

 

Concurrent kernel compilation 

If you only need to rebuild the kernel for your concurrent architecture and NetBSD version (a minor update is also allowed without re-building the tools), 

ftp -a ftp://ftp.fr.netbsd.org/pub/NetBSD/NetBSD-5.1/source/sets/syssrc.tgz
progress -zf syssrc.tgz tar xf -
mv usr/src/ .; rmdir usr/
cd src/
kernel=${HOSTNAME%%\.*}
cd sys/arch/amd64/conf/
cp GENERIC $kernel
vi $kernel
...
config $kernel
cd ../compile/$kernel/
make depend
make

 

Fetch the current sources 

By FTP, 

ftp -a ftp: //ftp.fr.netbsd.org/pub/NetBSD/NetBSD-current/tar_files/src.tar.gz
progress -zf src.tar.gz tar xf -
#tar xzf src.tar.gz
cd src/

Note. No need to 'mv usr/src/ .', with those tarballs, unlike the release's source, it's only the src/ dir that gets created. 

 

By CVS, 

CVSROOT=anoncvs@anoncvs.fr.netbsd.org:/cvsroot
CVS_RSH=ssh
export CVSROOT CVS_RSH
cvs -q -z9 checkout -P src

update later with, 

cd src/
cvs -q -z9 update -dP

 

Write a wrapper 

NetBSD provides the 'build.sh' script and it's eventhough handier to use a few wrappers on top of it. Create wrapper for the build.sh system, 

cd ~/
mkdir -p compile/
cd compile/
cat > ./scmake <<EOF9
#!/bin/ksh
[[ -z \$2 ]] && print \<arch\> \<tools\|release\> && exit 1
mkdir -p obj/ tools.\$1/ release/ dest/
cd src/
rm -f ../$2.log ../$2.errors.log
time ./build.sh -U -D ../dest -O ../obj -R ../release -T ../tools.$1 -u -m $1 $2 > ../$2.log 2> ../$2.errors.log
cd ../
EOF9
chmod +x scmake

Note. The '-u' option to not execute 'make distclean' every time. 

Note. The '-D' and '-R' options aren't really useful for the 'tools' target, but they don't harm. 

Note. When building for various architectures, some tools get recompiled again and again (plateform dependent parts like the compiler and linker). So I prefer to use seperate folders. 

Note. It writes to tools.log and tools.errors.log, use tail -f or -F to check how the compilation process is going. The 'time' output goes to the terminal, anything else goes to the mentioned logs. 

Note. Remove the '-U' option if you are using the root account on your system to compile netbsd. This is only required to do the whole thing as user (it is the case in this guide). 

 

Create the wipe-out wrapper to clean everything up, 

cat > ./scwipe <<EOF9
#!/bin/ksh
cd src/
make distclean
cd ../
rm -rf obj/ tools.*/ release/ dest/
EOF9
chmod +x scwipe

 

Compile using the wrapper 

Refer to the introduction to know if you need to build the tools or not. 

 

Build the tools, 

./scmake amd64 tools

or for another architecture, 

./scmake i386 tools

and check the logs in another window, 

tail -F tools.log

 

Eventually backup the tools (with the date of the used netbsd source), 

tar czf tools.i386.tar.gz tools.i386.current.20140104/

 

Build a specific (newer) kernel, 

cd src/
kernel=${HOSTNAME%%\.*}
cp arch/amd64/conf/GENERIC sys/arch/amd64/conf/$kernel
vi sys/arch/amd64/conf/$kernel
...
cd ../
./scmake amd64 kernel=$kernel

or cross-build anoher architecture's kernel, 

./scmake i386 kernel=$kernel

and check the logs in another window, 

kernel=${HOSTNAME%%\.*}
tail -F kernel=$kernel.log

 

Build the whole system, 

./scmake amd64 release

or cross-build another architecture, 

./scmake i386 release

and check the logs in another window, 

tail -F release.log

 

Applying kernel tweaks and patches 

Disabling OHCI 

Note. This is obsolete but kept as an example. OHCI wasn't the cause of keyboard issue, but simply a matter of connecting it to the right USB port (USB2 instead of USB3). 

 

You can make changes w/o the need to rebuild the whole thing e.g., 

grep ohci src/sys/arch/i386/conf/GENERIC
ls -l ./release/i386/binary/kernel/netbsd-GENERIC.gz
ls -l ./release/i386/binary/kernel/netbsd-INSTALL.gz
ls -l ./release/i386/binary/sets/kern-GENERIC.tgz

and copy/paste the sizes in some text document. Then proceed with the kernel changes, 

vi src/sys/arch/i386/conf/GENERIC
#ohci*  at pci? dev ? function ?        # Open Host Controller
#ohci*  at cardbus? function ?          # Open Host Controller
#usb*   at ohci?

and check that the sizes have changed, 

ls -l ./release/i386/binary/kernel/netbsd-GENERIC.gz
ls -l ./release/i386/binary/kernel/netbsd-INSTALL.gz
ls -l ./release/i386/binary/sets/kern-GENERIC.tgz

Note. Compilation time was 27975.07s (almost 8 hours) for the whole thing vs 1514.68s (25 minutes) for the little kernel modification. 

 

XEN patches 

And here's a few examples on how to apply patches against NetBSD. 

 

For the older xen domU network bug (fixed in current, not in 5.1), 

wget http://blog.yellowback.net/uploads/netbsd-5.99.27-xenfront-rx-copy.patch
cd src/sys/
patch -p0 < ../../netbsd-5.99.27-xenfront-rx-copy.patch
cd ../../

 

For the xen i386 guest multiprocessor beta-testing, 

wget ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/port-xen/breakout1/xen-pae-mp-pmap.diff
cd src/
patch -p0 < ../xen-pae-mp-pmap.diff
cd ../
grep -i multi src/sys/arch/i386/conf/XEN3_DOM0

 

Note. -s to make patch silent