Skip to end of metadata
Go to start of metadata

This document will help prepare you to build the source code for illumos. It assumes some familiarity with development on Unix-like systems.

You need an illumos-based operating system to build illumos (cross-compilation is not supported). If you don't have one installed, the quickest way to get started is to download and install either OpenIndiana from or OmniOS from . You may use a virtual machine – compilation performance may suffer, but it is functional. Some other distributions support self-hosting, including compilation of illumos-gate, as well.

Note: All commands in this guide assume you run them as an unprivileged user. sudo will be prepended to commands which need additional privileges; on some systems pfexec can be used instead, if your user has the correct RBAC profiles. The generic commands below use a $USER variable to define the current (unprivileged) user account's name which will ultimately be used to compile the project. If you are not using a stock shell or have manipulated the $USER variable in your environment at a site, system, or user level, you are responsible for diagnosing and addressing any consequences.

Note: VirtualBox 3.x has proven unfit for purpose in building from source (performance-wise – builds can take days instead of hours) and running debug kernels (systems have problems with clock discipline and are slow or become unresponsive). If you're interested in developing for illumos, consider running on bare metal or using an alternative virtualization product (KVM, VMware, Xen).

Update (2013-06-28): Some users have reported reasonable build times with recent (>= 4.2) versions of VirtualBox on recent Apple hardware. It is as yet unknown what specifically changed to resolve the issue, but presently it appears that recent VirtualBox may be more feasible. Until we know the specifics, consider VirtualBox unsuitable or experimental at best. More testing welcome! This only applies to building illumos, and not running debug kernels.

Installing required packages

You need to install several packages in order to build illumos.

  • Before downloading the required packages you will need to update the packages on the system. Build dependencies will occasionally be updated between media releases of OpenIndiana and OmniOS.

Package update
  • On OpenIndiana, the build-essential package contains most of what's required.  In addition, a Python 3 runtime and GCC version 7 are required for a complete build with shadow checks.
OpenIndiana packages
  • On OmniOS, the illumos-tools (meta)package is required:

OmniOS packages

Installing compilers

The source code was traditionally built using Sun's closed-source compiler suite, which was named Sun Studio at the time of the illumos fork.  We now build illumos with GCC.


The primary version of GCC necessary for development and integration 4.4.4 (4.4.4-il-4) should have been installed on your system when you installed the prerequisites above.  If for some reason that didn't happen (old build system, or the like), tarballs are available as described in the initial heads-up notice  2012-06-15 Illumos will now build with GCC 4.4.4 + patches.  We are presently also using GCC 7 as a shadow compiler as part of our effort to switch to GCC 7 for all builds (see bug 9996).

OpenIndiana Hipster 20161030

OpenIndiana Hipster 20161030 ships with gcc-4.4.4-il-3, so make sure to update that package to -il-4 before building.

Building with 4.4.4-il-3 leads to build failures with warnings as below in the mail_msg and nightly.log:

../../i86pc/os/trap.c:2188: error: unknown conversion type character '-' in format [-Wformat]
../../i86pc/os/trap.c:2188: error: too many arguments for format [-Wformat-extra-args]

Note that the compiler for building illumos-gate installs into /opt/gcc/4.4.4 on OpenIndiana, and /opt/gcc-4.4.4 on OmniOS; neither directory is in the default PATH for building application programs. You can add (OI example) PATH="/opt/gcc/4.4.4/bin:$PATH"; export PATH to your profile to reference this compiler, or install one of the other GCC builds, destined as the current default compiler for application programs (versions ranging from 3.4.3 to 4.6.x, see pkg info -r '*gcc*' for details du-jour).

Unfortunately, Sun Studio lint is currently required even for GCC-only builds.  We currently deliver Lint libraries built using the closed Sun Studio version of lint (see bug 10011).  OmniOS includes this in its sunstudio12.1 package.  On OpenIndiana it's delivered as part of the developer/sunstudio12u1/cc package, which is installed automatically as part of installing the build-essential metapackage (see above).

Sun Studio compilers

If you wish to attempt to build using the legacy Sun Studio compiler, you need specifically patched versions of both Studio 12 (used to compile) and 12.1 (used for lint) to get consistent results. These are no longer distributed by Oracle and can not be legally found in the open Internet.

NOTE: The illumos project no longer supports building with the Sun Studio compiler; this section is chiefly of historical, if any, interest.  The GCC compilers described in other sections are what most people are using today.

illumos-gate does not build correctly with Sun Studio versions released after 12.0. Reportedly using a newer version of the compiler will produce a system containing grave, data-corrupting bugs.  Patched compilers were previously available from Sun Microsystems, however not licensed for redistribution. After a recent Oracle site reorganization, the necessary compilers are no longer available.

If you have the patched versions of both Sun Studio 12 and 12.1, they should be installed in /opt/SUNWspro (Studio 12), and /opt/SUNWspro/sunstudio12.1 (Studio 12.1), respectively. Pay attention, the Studio 12.1 location is different from how it was in OpenSolaris, i.e. it's not /opt/sunstudio12.1.

The meta-procedure for cleaning up optionally prepackaged Sun Studio installations and installing the ones you require for building illumos (assuming your stashed Sun Studio 12 distribution archives are now pre-copied to /tmp) is as follows:

The first archive contains the product component sub-directories directly at the top-level, and the second has similar sub-directories under the top-level sunstudio12.1 as its children. Thus you receive the structure outlined above.

You can check if you have the correct versions installed as follows. All of the following tests must succeed and return these specific product/patch versions:

You must then adjust your nightly(1) environment file (i.e. by adding a line in to specify that Studio should be used as the default compiler, by adding:

Building illumos

Preparing the source-code directory

You can use any location, but for the purposes of this guide, we will assume that you have a directory /code owned by your user ID, which you are using to obtain source and build.

For a less naive example, see the Build datasets page and some more industrious details on Managing multiple workspaces and Working on several bugs at once.

Getting the source

You may use the Git source code management system to retrieve the illumos source code. Make sure you have about 6 gigabytes of free space for the source and binaries combined.

The repository is available from GitHub using the Git source code control system.

For best results, use the HTTPS URL to clone from Github:

The illumos-gate source can be cloned using:

Getting closed binaries

There are still closed components in illumos that have not yet been replaced. You must get the latest closed binaries from Sun/Oracle, since illumos currently needs those in order to build.

 OmniOS and OpenIndiana users have these tarballs installed in /opt/onbld/closed, and ON_CLOSED_BINS can be set to point to this directory directly. The following step is not required on these systems.

Note that if you had a crypto tarball from an earlier build, do not use it here, as it is no longer required to build illumos. You should remove it from your tree if already present.

According to the gcc-4.4.4-il heads-up note, the kernel modules among the closed binaries might need some fixup for proper compilation. According to several developers, however, they've never needed to do this in practice. Just in case you are trying to build some older branch of illumos which might require this modification and inexplicably breaks without it, the steps are outlined below in the troubleshooting section.

Preparing the build environment

General build configuration

The build is configured using a shell script with environment variables, a template for this file is included:

The settings we are going to focus on for now are the following:

  • CODEMGR_WS - This should be the root of the directory with the code. If you followed the previous example, it will be /code/illumos-gate.
  • STAFFER - Change this to the name of the non-privileged user you use on the system
  • VERSION - Set this to illumos-gate or whatever version string you want for the build

ImportantONNV_BUILDNUM specifies the build number which is used in packaging. If you intend to upgrade a system whose build number is greater than the one in illumos-gate (currently 148), such as OmniOS you need to specify this to allow upgrades until issue #1118 is addressed. Run:

If you see, for example, "Branch: 0.151.1", you must choose a number greater than the part after the leading "0.". For example, add

to the script.

On OpenIndiana you'll likely see something like 'Branch: 2019.0.0.16790'. You have to use PKGVERS_BRANCH to overwrite this value, you can't use ONNV_BUILDNUM for this purpose. You should set PKGVERS_BRANCH in a form of YEAR.MAJOR.0.0 , where YEAR is the current year and MAJOR is greater that the one used by OpenIndiana. For example:  

Building with only GCC-4.4.4-il (i.e. without using Sun Studio at all)

NOTE: This configuration is recommended for most users.

If you are building with solely GCC 4.4.4 (i.e. you do NOT wish to use Sun Studio at all), you must append these lines to the end of

This should suffice for compilation of modern illumos-gate sources executed on a modern distribution. Older branches (circa 2012) might need some more setup which, along with explanation of the options, can be found below in the troubleshooting section.

OmniOS Modifications

In order to build illumos-gate on OmniOS, use version r151028 or higher. OmniOS has sample build files in /opt/onbld/env/omnios-* for use with illumos-gate or illumos-omnios.  If you roll your own env files, read on. You can also find sample environment files for building on different OmniOS releases at

OmniOS modifications

You must also make sure you disable IPP and SMB printing support on the default OmniOS installation by commenting out the following lines.

If you need to also compile IPP and SMB printing, you must provide the Apache, Apr/Apr-util for IPP or CUPS headers for SMB printing.

OpenIndiana Modifications

To build illumos-gate on OpenIndiana , you'll have to customize in the following way:

OpenIndiana Hipster mods

Starting the build

You are now ready to start the illumos build.

Since this process may take up to several hours depending on your system (reference build times are in a chart below), it may be wise to start the build job in a VNC session, GNU Screen (screen), or tmux. The screen program can be installed with the pkg:/terminal/screen package.

Run the following command to start the full build:

Note that the command does not give any progress output. You can instead follow the log file at log/nightly.log, which is updated (slowly) during the build process. In another terminal, run:

To only track the running build for warnings and errors you might instead run:

After the build is complete, the nightly.log file and some other generated logs are moved into a uniquely named subdirectory log/log.$TIMESTAMP/ (i.e. /code/illumos-gate/log/log.2012-04-20.04\:17/ ).

A dry overview of the build progress (hopefully small – about 2KB in size – with no errors) is saved in log/log.$TIMESTAMP/mail_msg file intended for mailing to the build administrator after the build completes (this automation is out of the scope of the script). If you do receive any errors in the mail_msg report file, you can grep the error lines in the larger nightly.log file.

Performing an incremental build

If you've made changes after completing a nightly build, you can perform an incremental build without discarding the already built files.

To make this the default, edit and add the character i to NIGHTLY_OPTIONS.

Before submitting a patch, we request that you perform a full, non-incremental build.

Building specific components, and other info

Installing built software

Installing the nightly build on local machine with onu script

The build process will generate updated packages. Depending on the NIGHTLY_OPTIONS variable in script, the packages will be written either to $PWD/packages/i386/nightly (with debug, the typical default) or to $PWD/packages/i386/nightly-nd (without debug). Therefore there are two possible commands to install the software you you just built. You need choose the proper onu command, typically the first one listed below.

Typical install: you can install with onu for debug builds (the default, with 'F' and 'D' characters in NIGHTLY_OPTIONS variable in

NOTE: For OmniOS and OpenIndiana, it is critical that the PKGVERS_BRANCH is properly set in the env file (see above); otherwise, ONU will fail.

The non-typical installs are detailed in the following pages:

Possible problems

In any case, if you have build errors or other "inconsistencies", it would be wise to revise the mail_msg logfile that can contain short error descriptions, and grep for those errors in the longer nightly.log file. If that doesn't help, you should also recreate the build in a "clean lab" environment, which may be set up as a local zone according to the Building in zones instructions and rule out the local environment's influence (conflicting libraries and binaries, perhaps from your own earlier builds, come to mind first).

Localization bugs #167 and #168

illumos has entirely different localization infrastructure from Solaris, so your existing system locales will not work.

The English locales for illumos are in pkg:/locale/en (NOT pkg:/system/locale/en), and if you wish to use them, you'll need to install that package after you reboot. Likewise, other locales are in pkg:/locale/<language code> where <language code> is a two letter ISO 639-1 code, except for zh_cn/zh_hk/zh_mo/zh_sg/zh_tw.

If your locale is not installed, it will cause problems with software which behaves badly if setlocale() fails. This includes, at least, time-slider and svcs(1M). The pkg(5) commands print a warning, but function normally.

If this is a problem, you can  "export LANG=C LC_ALL=C" as a workaround, and change the LANG setting in/etc/default/init to 'C' (and reboot) to make the change permanent.

Package repository (path /code/illumos-gate/packages/i386/nightly/repo.redist) is not created and onu script fails

This error has happened to me whenever I ran the default checkout and full-build procedure outlined above (in VirtualBox VMs); I don't yet know why (possibly due to a wrong setup of my SunStudio compiler stack, as was later discovered).
However, rerunning with an incremental build has created the package repository correctly (as well as full builds with proper SunStudio setup):


Ensuring a build with only GCC-4.4.4-il for older branches of illumos

illumos-gate as of March 2014 should compile cleanly with GCC with the simplified instructions above. However, some earlier versions of the gate needed more configuration steps to compile properly, and the settings below shouldn't break anything for the newer source code as well (wink)

If you are building with solely GCC 4.4.4 (i.e. you do NOT wish to use Sun Studio at all), you must append these lines to the end of

Explanation of these settings:

  • CW_NO_SHADOW - Set this to 1 to prevent the shadow compiler from running (for instance, if you do not have Studio at all, in which case a regular build would fail due to "cw: error: couldn't run /opt/SUNWspro/bin/cc (No such file or directory)" and inability to run the shadow compilation and thus verify the fitness of code for both supported compilers).
  • ONLY_LINT_DEFS - This is needed so the lint is able to find the proper note.h include file.
  • If __GNUC is defined, then a GCC would be the primary compiler. If __GNUC4 (or legacy __GNUC3) is defined, then the particular version of the compiler is used. Remember to unset __SUNC to properly use just one primary compiler (wink) and use CW_NO_SHADOW=1 as described above to completely disable a secondary (shadow) compiler.

The last two lines make sure the patched version of GCC-4.4.4 is used (the default gcc version shipped with e.g. earlier OpenIndiana, gcc-3.4.3, is not suitable for building illumos), as described here.

If you are trying to build with GCC 4.4.4 and your build fails because of some invalid GCC warning options, try setting the variables GCC_ROOT and CW_GCC_DIR as shown above and described here.

While recently rebuilding a historical 2012 version of illumos-gate with GCC-4.4.4-only setup per instructions above, I've still got Sun Studio errors in my mail_msg file like:

 or more frightening:

 However, the files in proto/ and packages/ were created successfully. So... even error reports may need manual verification before panic and frantic fixes (wink)

Command failed for target `packages.i386/developer-dtrace.dep'

4719 introduces a flag day for people who build illumos-gate. You will need a Java Developers Kit (JDK) 7 or later. OpenIndiana 151a9 does NOT have this by default.

Symptoms: Users still on JDK6 will see build errors in the packaging portions like such:

Cause: These are due to javadoc changes between 6 and 7.  The dtrace and mdns packages generate javadoc, so their packaging manifests are updated to the 7 versions.

Cure: Builders must either set JAVA_ROOT to an installation location of JDK7, or must have /usr/java populated with JDK7 (or pointing to an installation location of JDK7). You can use whatever distribution of JDK7+ works for you best (packages or tarballs, OpenJDK or Sun/Oracle JDK).

If you are on the latest OpenIndiana, you want to install runtime/java/openjdk8 and developer/java/openjdk8 packages. Then in your env file, set:

Build times

As a convenience, we will try to assemble some build times for various hardware configurations here, so you can get an idea in advance of how long it will take:

Processor(s)No. of coresMemoryTime (HH:MM)Notes
2 x Xeon X5570 2.93GHz2 x 436 GB00:19NIGHTLY_OPTIONS='-FnCDmprt'
4 x Opteron 6172 2.1 GHz4 x 12128 GB00:21NIGHTLY_OPTIONS='-FnCDmprt'
Xeon E3-1270 3.4 GHz416 GB00:23NIGHTLY_OPTIONS='-FnCDmprt'
Core i7-3770 3.4GHz48 GB00:28NIGHTLY_OPTIONS='-nCprt' (with SSD, the production build for Tribblix)
Xeon E3-1245V2 3.4 GHz416 GB00:31NIGHTLY_OPTIONS='-FnCDmprt'
Core i7-2600K 3.4 GHz48 GB00:35NIGHTLY_OPTIONS='-nClmprt'
2 x Xeon E5620 2.4 GHz2 x 448 GB00:38None
1 x Xeon E5607 2.27GHz1 x 412 GB00:46NIGHTLY_OPTIONS='-FnCDmprt'
Xeon E3-1245V2 3.4 GHz416 GB00:47NIGHTLY_OPTIONS='-FnCDlmprt' (with lint)
2 x Xeon E5540 2.53 GHz2 x 424 GB00:50With lint
2 x Xeon E5506 2.13 GHz2 x 424 GB00:50No dmake check
1 x Xeon X5650 2.67 GHz1 x 612 GB00:51With lint, default NIGHTLY_OPTIONS
2 x Xeon E5506 2.13 GHz2 x 424 GB01:03None
Core i7-960 3.2 GHz49 GB01:03With lint
2 x Xeon E5506 2.13 GHz2 x 416 GB01:06VMware Workstation guest
Core i7-930 2.8 GHz48 GB01:07VMware ESXi guest
Xeon  E5-2676 v3 2.4GHz216 GB01:13NIGHTLY_OPTIONS='-nCprt' (Tribblix) on an AWS m4.xlarge EC2 instance
Core 2 Quad Q6600 2.4 GHz42 GB01:16None
2 x Xeon E5310 1.6 GHz2 x 432 GB01:24None
1 x Athlon II X2 240 2.8 GHz22 GB01:27NIGHTLY_OPTIONS='-FnCDmprt', on a low end SSD
Core 2 Quad Q9300 2.5 GHz47 GB01:32None
2 x Xeon E5420 @ 2.50GHz2 x 44 GB01:33Default NIGHTLY_OPTIONS; an incremental rebuild takes 13 min to walk all Makefiles
2 x Opteron 2218HE 2.6 GHz2 x 216 GB01:42None
Core i5-540M 2.53 GHz24 GB01:54None
2 x UltraSPARC-T2+ 1165 MHz128 threads32 GB02:18NIGHTLY_OPTIONS='-nCprt' (the Tribblix SPARC build)
Core i3-370M 2.40 GHz22 GB02:30None
Core 2 Quad Q8200 2.33 GHz45 GB02:30Default NIGHTLY_OPTIONS.
Core 2 Duo T8300 2.3 GHz (T61)22 GB02:58VMware Workstation 2 CPUs
Core 2 Duo E6750 2.66 GHz28 GB02:59Sun Ultra 24 (with lint)
Core 2 Duo Celeron E3200 3.2 GHz24 GB03:282.4 GHz CPU over clocked to 3.2. Everything running on a low end SSD. With lint.
Core 2 Duo T5600 1.8 GHz23.3 GB04:26None
Opteron 146 2 GHz14 GB07:28None
4 x Dual-Core Opteron 8218 2.6 GHz (8-vCPU VM) 16 GB (2GB VM)35:47 + 9:05VirtualBox 3.0.12 VM, with 8 vCPUs and 2GB vRAM; local vHDD; with lint and default NIGHTLY_OPTIONS='-FnCDlmprt'

NOTE: Package repo did not get built at all with the first nightly run, only with the second, incremental nightly run (another 9 hours)



  1. "Bare Metal" just slightly faster than VMware guest. On the other hand, VirtualBox painfully slow.
  2. More cores faster but not linear increase.
  3. SSD use seems to provide nice speedup.
  4. As expected, lint checking results in longer build times.