This is for cross-compiling MINIX from another Unix-like system. To build MINIX from within MINIX, check this page instead.
|Host platform||Version||Buildable MINIX architectures||Version||Updated|
|Ubuntu x86 32-bit||14.04||x86 32-bit / ARMv7||3.4.0rc||2016-02|
|Ubuntu x86 64-bit||14.04||x86 32-bit / ARMv7||3.4.0rc||2016-02|
|Arch Linux x86 32-bit||x86 32-bit||3.2.1||2013-08|
|Arch Linux x86 64-bit||x86 32-bit / ARMv7||3.2.1||2013-08|
|Mac OS X Lion x86 64-bit||x86 32-bit / ARMv7||3.2.1||2013-08|
|Mac OS X Maverick x86 64-bit||x86 32-bit / ARMv7||3.3.0||2014-10|
|FreeBSD x86 32-bit||10-CURR.||x86 32-bit / ARMv7||3.2.1||2013-08|
|FreeBSD x86 64-bit||10-CURR.||x86 32-bit / ARMv7||3.2.1||2013-08|
The first step to crosscompile MINIX is to obtain the sources and build the cross-compilation tools. MINIX has adopted NetBSD's
build.sh script to create the cross-compiler. There are some wrapper scripts that will build a ready-to-boot system from scratch (i.e. just the minix source tree) for either x86 or ARM.
$ git clone git://git.minix3.org/minix minixsrc $ cd minixsrc
NOTE: The releasetools script will generate object files and put them outside the source directory; it will move up out of the git repo and start touching stuff there. I.e., if you've cloned to ~/foo/minixsrc/ and build from there, things will start showing up in ~/foo/ as an artifact of the build process. You probably don't want this (and the build process probably shouldn't do this…), so if that's a problem for you, try double-wrapping it: instead of cloning to ~/foo/minixsrc/ try creating a “minix” container directory and cloning to ~/foo/minix/src.
The wrapper script for x86 generates a harddisk image ready to boot - except that it currently relies on an outside multiboot implementation. KVM provides this. It's very convenient also for passing args from the outside into the VM. The script produces a lot of output and will take a long time the first time - it generates a cross-toolchain from scratch based on LLVM.
$ bash ./releasetools/x86_hdimage.sh [..] Writing Minix filesystem images - ROOT - USR - HOME Part First Last Base Size Kb 0 0/000/00 0/000/07 0 8 4 1 0/000/08 64/000/07 8 131072 65536 2 64/000/08 1856/000/07 131080 3670016 1835008 3 1856/000/08 1984/000/07 3801096 262144 131072 To boot this image on kvm: [..]
The printed kvm command line loads all the boot modules in the right order, sets the right variables (minix needs to know the rootdevname) and sets the console for serial.
A similar procedure exists for ARM. Please see MinixOnARM for much more information.
From a source directory:
$ sh build.sh -mi386 -O ../build tools
Please note that by default, the build.sh script will output the built objects to
/usr/obj, so make sure it exists. Alternatively, use as above the “-O” option to redirect the output to somewhere else. When this process is completed, you'll have a ../build/tooldir.<something> directory. The <something> is roughly equivalent to
$ echo ''uname -s''-''uname -r''-''uname -m''
Among the tools that are built are
gmake. The sources for these tools are not provided by us. Instead, they are downloaded on-the-fly as tarballs from the minix webserver
Note: For Cross compiling on Ubuntu , an extra library is to be installed , i.e the zlibc To install it run the following command :
$ sudo apt-get install zlibc zlib1g zlib1g-dev
Note: Also on Ubuntu, if you get an error stating that “'/lib/cpp' fails sanity check”, you need to install the GNU C++ compiler:
$ sudo apt-get install g++
Note: Again on Ubuntu,
curl tool, which needs to be installed:
$ sudo apt-get install curl
Note: On FreeBSD and Minix (compiling for ARM on x86, e.g.), if you get a message along the lines of “Skipping image creation: missing tool 'mcopy'”, please install the emulators/mtools package.
The next step is to actually build MINIX:
$ sh build.sh -mi386 -O ../build -U distribution
This process will create a ../build/destdir.i386 directory that holds the built distribution of MINIX.
Other useful options for qemu are
-monitor telnet::4444,server,nowait (to access some interesting internal state by telnet) and
-serial stdio - for convenient debug output over 'serial.'
To run make in the cross-environment, i.e. to rebuild a tool (host target) or minix item (minix target), without running the full build.sh procedure all over again, use nbmake-i386, a make wrapper that sets all the right environment. First expand your $PATH to include it:
$ PATH=$PATH:OBJDIR/tooldir.OS-VERSION-ARCH/bin/ $ cd SRCDIR/tools $ nbmake-i386 clean $ nbmake-i386
will rebuild all the tools. After that you can e.g.
$ cd zic $ nbmake-i386 clean $ nbmake-i386
to just rebuild zic. As you can tell if you set MAKEVERBOSE=2, tools/zic/ will invoke cc (to run on the host platform), whereas nbmake-i386 will invoke i486–netbsdelf-gcc from your tools dir if you run it in usr.sbin/zic/, so a Minix-targeted binary is produced.
build.sh is tailored towards NetBSD and as such not all features make sense for MINIX. For example, we don't have a kernel configuration file. Also, you can't use
build.sh for native builds on MINIX at the time of this writing. You can consult
build.sh's documentation by invoking:
$ sh build.sh
But know that not all operations and options are supported. For example, we only support the
distribution build operation. You can't generate iso images with the
It is possible to tweak the build using build flags. Here are some you might find useful.
|COPTS||c flags||COPTS=-g||c compiler opttions|
It is also possible to tweak when building separate components using nbmake-i386
|MAKEVERBOSE||||MAKEVERBOSE=2||Instruct make to be more verbose|
1. Load the loop kernel module, or adapt kernel command line:
$ modprobe loop max_part=15
or add to your kernel commandline : max_part=15
2. Setup a loopback device to point to your disk image:
$ losetup /dev/loop0 minix.img
3. (Optional) list the available partitions:
$ dmesg | tail
$ ls /dev/loop0*
4. Mount the desired partition somewhere
$ mount /dev/loop0p5 /mnt