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