Version 17 (modified by benl, 9 years ago) (diff)

Add list of failing regression tests

Building on Solaris

These instructions have only been checked for GHC 6.12.1 on Solaris 10 on SPARC. They should also apply to later versions of GHC, Solaris 8 and later, and perhaps Solaris on x86.

GHC versions 6.10.1 and earlier don't have a working SPARC native code generator, and have many small build issues with Solaris. Use GHC 6.12.1 or later.

Installing GNU packages

GHC relies on many GNU-isms that are not supported by the native Solaris build tools. The following environment is known to work. Later versions may work but have not been tested. Taking the time to install these tools is likely to be less painful than debugging build problems due to unsupported versions (and this is your official warning).

GNU binutils 2.20 for GNU ld, maybe others
GNU coreutils 8.4 for GNU tr, maybe others
GNU make 3.81 make files use GNU extensions
GNU m4 1.4.13
GNU sed 4.2 build scripts use GNU extensions
GNU tar 1.20 Solaris tar doesn't handle large file names
GNU grep 2.5 build scripts use GNU extensions
GNU readline 5
GNU ncurses 5.5
Python 2.6.4 needed to run the testsuite with multiple threads
GCC 4.1.2 this exact version is needed

Some of these can be obtained as binary versions from the collection, others need to be downloaded as source from

The blastwave libraries are usually installed under /opt/csw, so you may need to manually set LD_LIBRARY_PATH to point to them:

export LD_LIBRARY_PATH=/opt/csw/lib

Using a bootstrapping GHC

You can either get a binary distribution from the GHC download page or use some other pre-existing GHC binary. These binaries usually assume that required libraries are reachable via LD_LIBRARY_PATH, or are in /opt/csw. If you get errors about missing libraries or header files, then the easiest solution is to create soft links to them in, lib/ghc-6.12.1 and lib/ghc-6.12.1/include of the installed binary distribution. These paths are always searched for libraries / headers.

What can go wrong

The rest of this page discusses problems with specific tool versions. If you stick to the versions in the above list then you shouldn't have to read further.

Only some GCC versions work

  • GCC version 4.1.2 is known to work. Use this version if possible.

On Solaris 10, /usr/bin/gcc is "GCC for Sun Systems (gccfss)". This is a version that uses Sun's code generator backend. This is completely unusable for GHC because GHC has to post-process (mangle) the assembly output of GCC. It expects the format and layout that the normal GCC uses.

The version of /usr/sfw/bin/gcc on Solaris 10 is 3.4.x which has problems, see below.

GCC version 4.3.x produces assembly files that GHC's "evil mangler" does not yet deal with.

GCC version 4.2.x works but takes hours and hours to build the large .hc files that GHC generates. It is reported (#1293, #2906) that particular modules can take upwards of 5 hours and the overall build takes a couple days. This is due to complexity issues with respect to GCC moving to a unit-at-a-time compilation scheme instead of function-at-a-time.

GCC version 4.0.2 does not support thread local state (TLS), at least on SPARC.

GCC version 3.4.x is reported (#951) to mis-compile the runtime system leading to a runtime error schedule: re-entered unsafely. But such a gcc version is sufficient for most user programs in case you just installed a ghc binary distribution.

Split objects

Split object didn't work in GHC 6.10.x, not sure about GHC 6.12.1.

It worked on Solaris 10 with ghc-6.8.3, gcc-4.1.2 and the system (not GNU) binutils (ie as, ld etc from /usr/ccs/bin).

If you run into linker problems then you can try turning it off by adding the following to your mk/


Test Failures

The following regression tests are known to fail on SPARC/Solaris10 with GHC 6.12.1, using the 6.12.1 testsuite. Some of these are not platform specific.

Unexpected failures: