Building GCC 4.x on Solaris

I needed to build GCC 4.3.1 for my x86 system running a recent
development build of Solaris. I thought I would share what I
discovered, and then improved on.

I started with href="http://paulbeachsblog.blogspot.com/2008/03/building-gcc-421-on-solaris.html">
Paul Beach's Blog on the same topic, but I knew it had a couple of
shortcomings, namely:

  • No mention of a couple of pre-requisites that are mentioned in
    the GCC document href="http://gcc.gnu.org/install/prerequisites.html">Prerequisites
    for GCC
  • A mysterious "cannot compute suffix of object files" error in the
    build phase
  • No resolution of how to generate binaries that have a useful
    RPATH (see
    Shared Library Search Paths
    for a discussion on the importance of

I found some help on this via
this forum post
, but here is my own cheat sheet.

  1. Download & install GNU Multiple Precision Library (GMP)
    version 4.1 (or later) from
    . This will end up located in /usr/local.
  2. Download, build & install MPFR Library version 2.3.0 (or
    later) from mpfr.org. This will
    also end up in /usr/local.
  3. Download & unpack the GCC 4.x base source (the one of the
    form gcc-4.x.x.tar.gz) from gcc.gnu.org
  4. Download my example config_make script, edit as desired (you
    probably want to change OBJDIR and PREFIX, and you may want to add
    other configure options.
  5. Run the config_make script
  6. "gmake install" as root (although I instead create the directory
    matching PREFIX, make it writable by the account doing the build, then
    "gmake install" using that account).

You should now have GCC binaries that look for the shared libraries
they need in /usr/sfw/lib, /usr/local/lib and PREFIX/lib, without
anyone needing to set LD_LIBRARY_PATH. In particular, modern versions
of Solaris will have a libgcc_s.so in /usr/sfw/lib.

If you copy your GMP and MPFR shared libraries (which seem to be
needed by parts of the compiler) into PREFIX/lib, you will also have
a self-contained directory tree that you can deploy to any similar
system more simply (e.g. via rsync, tar, cpio, "scp -pr", ...)

Join the discussion

Comments ( 4 )
  • UX-admin Friday, September 5, 2008

    You would be surprised how many people don't understand how the compile & linking processes work on UNIX in general, and especially how many people don't understand what -R is for.

    And that's just the beginning, I won't even go into discussing -R '$ORIGIN', that would really cause a whole bunch of glazed looks and drooling at the mouth.

    It's a really sad and alarming state of affairs. Between the "Gray beards" and short attention span generation Y, this essential knowledge was somehow lost; I've been working to repair the state of affairs as much as I can, but more knowledgeable instructors & mentors are needed.

    Apropos the article on Paul Beach's blog:

    IRIX uses -R as well, and it works exactly as it does under Solaris. HP-UX's encodes the path to the shared object libraries based on the values of -L, and whether it actually finds the shared object libraries where -L points to. When I think about it, that's really neat, I wish Solaris and IRIX did that as well. Although HP-UX does not produce ELF binaries for 32-bit objects and executables, it does use ELF for 64-bit objects and binary executables; but even in 64-bit, the linker relies on the value -L to encode the runtime link paths. Interestingly enough, just like on Solaris, HP-UX's ld supports -R '$ORIGIN' as well.

    I just love System V.

  • Cyril Friday, September 12, 2008

    Gcc 4.2.4 and all gcc 4.3.x seems to be uncompilable because of a ld bug in solaris 10.

    (bugid 6685125).

    we are stuck in 4.2.3.

    The bug is fix in opensolaris but not in the official solaris 10.

    Do you know a way around it ?

  • gerard Friday, November 14, 2008

    why don't you use SFE way?


    there is a SFEgcc.spec about 4.2.3.

    It's very difficult to maintain too many differents packages. We need to deploy FOSS as fast as possible on solaris 10 x86 platforms, not to spend our time to recompile what others have already compiled

  • anonymous Monday, November 24, 2008
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.