HEADS UP: Illumos will now build with GCC 4.4.4 + patches
If you don't build illumos, or don't care about how you build illumos you can safely ignore this message. If you contribute to illumos please do read this.
Illumos may now be built with a patched version of GCC 4.4.4. It is neither the default compiler, nor the default shadow compiler at present.
The patched GCC is available from:
- source: https://github.com/illumos/gcc/tarball/gcc-4.4.4-il-2
- x86: http://richlowe.openindiana.org/~richlowe/il-gcc-444-i386.tar.bz2
- sparc: http://richlowe.openindiana.org/~richlowe/il-gcc-444-sparc.tar.bz2
The binaries expect to be in
As far as distributions go I believe the current state is this:
- SmartOS makes its own arrangements, and has been using this work for a while
- OmniOS does not make it available
- OpenIndiana are in the process of making it available, I think
How to use it
This is not another shadow compiler, nor is it a general build-time knob (though it may be used as one, with minor env file changes on your part). This is instead a means to change the version of GCC which is used in general.
There are several variables which control this:
__GNUC - Influences whether GCC is the primary or shadow compiler, as always.
The following are new:
__GNUC3 - The default, indicates that the version of GCC to be used is the patched GCC 3.4 commonly found in /usr/sfw
__GNUC4 - Indicates that the version of GCC to be used is the patched GCC 4.4.4.
GCC_ROOT - The path to the prefix to which the patched GCC was installed (defaults to
Tools built for GCC 4 will use GCC 4 by default, and tools built for GCC 3 will use GCC 3 by default, if you need to override this (to toggle quickly back and forth between GCC 3 and GCC 4, for instance) you must also set
CW_GCC_DIR to the directory containing the gcc binary in question, so that your existing build tools will use the GCC in question, while re-building themselves. The first time you build using GCC 4, you will have tools in
/opt/onbld that will default to using GCC 3 and so you will also need to set
CW_GCC_DIR. This is true regardless of whether GCC is the primary or shadow compiler.
Thus, if you want to build with Sun Studio, but GCC 4.x as the shadow your environment file should contain:
If you want to use GCC4 as the primary compiler, it should contain:
And if you are switching between versions, both examples should also contain:
Fix your closed-bins
There's an important catch here. As is the case with GCC 3, the closed kernel modules which had their CTF information merged against the June 2010 genunix will need that CTF information removed to avoid causing problems for both DTrace and mdb.
You can do this by running
mcs -d -n .SUNW_ctf <file> for each closed kernel module. The most important ones are
mpt, which cause problems for DTrace, however anything derived from the CTF of any other closed module will also be incorrect. You may want to remove the CTF from all of your (kernel) closed binaries (you should keep a pristine copy, if you do this.)
Building old source on top of these bits will fail
Due to bug 2860 "tools elfsign uses erroneous mix of headers", building sources prior to this putback on a build machine running bits from this putback or later will fail. This is unavoidable. Sorry.
If you're an illumos developer
I'd really appreciate it if you started using GCC 4 in place of GCC 3 (as would downstream people already defaulting to GCC 4).
There is a plan, at some time in the possibly near future, to make GCC 4 the default version of gcc (used, by default, as the shadow compiler). We're waiting on its easy availability from distributions, and that's not necessarily a hard precondition.
At present, until the default changes, it is likely best that you continue to use GCC 3 for your RTIs, on the principle that we really don't want either build to break, but we want the default configuration to break the least.
If you break the GCC 3 shadow build, you will be backed out. If you break the GCC 4 shadow build, you'll probably just be asked to fix it (or I'll fix it).
You will see build noise as you switch between primary compilers
Because each compiler has its own set of private symbols which get inserted into built objects, you're going to see a lot of ELF runtime noise as you switch between primary compilers. It is in your interests to make sure these builds are separate from any which could legitimately cause runtime noise (and to try to avoid letting this noise into RTIs, where it's very annoying to sift).