Skip to end of metadata
Go to start of metadata

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.

Summary

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:

The binaries expect to be in /opt/gcc/4.4.4

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 /opt/gcc/4.4.4)

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:

GCC_ROOT=/where/you/put/gcc
__GNUC4=""

If you want to use GCC4 as the primary compiler, it should contain:

GCC_ROOT=/where/you/put/gcc
__GNUC=""
__GNUC4=""

And if you are switching between versions, both examples should also contain:

CW_GCC_DIR=/where/you/put/gcc/bin

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 klmmod, klmops and 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).

Labels:
  1. Jun 23, 2012

    Thought I'd give this a run as a standard compiler, but after unpacking to /opt I noticed the following:


    ~$ /opt/gcc/4.4.4/bin/cpp -v
    Using built-in specs.
    Target: i386-pc-solaris2.11
    Configured with: ../../configure --prefix=/opt/gcc/4.4.4 --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld --enable-languages=c,c++,objc --enable-shared --with-mpfr-include=/usr/include/mpfr --with-gmp-include=/usr/include/gmp --with-pkgversion='Illumos tags/gcc-4.4.4-il-2' --with-bugurl=http://github.com/richlowe/gcc/issues
    Thread model: posix
    gcc version 4.4.4 (Illumos tags/gcc-4.4.4-il-2)
    COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=i386'
     /opt/gcc/4.4.4/libexec/gcc/i386-pc-solaris2.11/4.4.4/cc1 -E -quiet -v - -mtune=i386
    ignoring nonexistent directory "/opt/gcc/4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../../i386-pc-solaris2.11/include"
    #include "..." search starts here:
    #include <...> search starts here:
     /usr/local/include
     /opt/gcc/4.4.4/include
     /opt/gcc/4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/include
     /opt/gcc/4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/include-fixed
     /usr/include
    End of search list.
    ^C

    Did I do something wrong?