|Version 5 (modified by maeder, 6 years ago) (diff)|
Building on Solaris
These instructions have only been checked for GHC 6.8.3 on Solaris 10 on SPARC. It should mostly apply to later versions of GHC, Solaris 8 and later and perhaps Solaris on x86.
Using the right GCC
Avoid the system GCC versions
On Solaris 10, the /usr/bin/gcc is a version that uses Sun's code generator backend. This is completely unusable for ghc because ghc has to post-process the assembly output of gcc. It expects the format and layout that the normal gcc uses.
The /usr/sfw/bin/gcc version (at least on Solaris 10) is 3.4.x which is reported to have problems, see below.
It is recommended therefor to install another gcc package, either from some Solaris binary package or to build a vanilla gcc from source.
Selecting a good GCC version
GCC version 4.1.x and 4.0.x seem to be fine. 4.1.2 is recommended.
GCC version 3.4.x is reported 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.
GHC has not yet been updated to understand the assembly output of GCC version 4.3.x.
GCC version 4.2.x works but takes hours and hours to build the large .hc files that GHC generates. It is reported that particular modules can take upwards of 5 hours and the overall build takes a couple days.
Using GCC from a non-standard location
Since the recommendation is not to use the system /usr/bin/gcc then it is necessary to configure GHC to use a different GCC. Not only do we have to ensure that this alternate GCC is used while building GHC, but we must ensure that this alternate GCC is used by default by the built GHC once we install it and try to use it. Otherwise it will default to whatever gcc is on the $PATH which would typically be /usr/bin/gcc again.
Due to a bug in the build system (#2966) it is not enough to specify --with-gcc= when running ./configure. It is necessary to adjust the $PATH so that the correct gcc is found *and* to use --with-gcc= to the full path to that same version of gcc. Having it first in the $PATH is required for the build to go through and the --with-gcc= flag is necessary to have the resulting ghc use that gcc once installed.
export PATH=/opt/gcc-vanilla/bin:$PATH ./configure --with-gcc=/opt/gcc-vanilla/bin/gcc
Fixing the unix package
At the time of writing the unix package gets built wrong (see #2969) which results in getSymbolicLinkStatus not working which in turn breaks darcs. The fix is given in the ticket.
TODO attach a patch for ghc-6.8.3, send in a patch for ghc-6.10.x and HEAD.
Using GMP and other libs from non-standard locations
The gmp library is not a standard system library on Solaris. It can usually be installed from a third party binary package collection or built from source. Either way it will usually not be on the standard cpp include path or the standard static linker path, or the standard dynamic linker path.
We can handle the first two aspects with these ./configure flags --with-gmp-includes and --with-gmp-libraries.
For example, using gmp installed from the 'blastwave' package collection:
./configure --with-gmp-includes=/opt/csw/include --with-gmp-libraries=/opt/csw/lib
However to actually run programs compiled by ghc (such as stage1) that use gmp from this location we need to link them in such a way that they will find the gmp lib at runtime. The best way is to use the -R linker flag to 'bake in' the right path.
This can be specified in the mk/build.mk file by using:
TODO check this works, it was only tested with a bootstrapping ghc that always used the above flag, baked into the driver shell script. In that case only GhcStage2HcOpts=-optl-R/opt/csw/lib was needed.
With the right toolchain this can work. It's been tested 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 problems however turn it off by adding this to your mk/build.mk:
Note that to use split objects at the moment you need your gcc to default to the SPARC V9 ABI or to tell ghc to tell gcc to use the V9 ABI it when assembling (-opta-mcpu=v9) otherwise you'll hit bug #2872.
Putting it all together
This example uses ghc-6.8.3 on Solaris 10, using gmp and other tools from the 'blastwave' collection installed in /opt/csw. The gcc is 4.1.2 install in /opt/ghc-vanilla/4.1.2/bin. The bootstrapping ghc is the binary from the ghc download page installed in /opt/ghc-bin.
The mk/build.mk file is
The ./configure options
./configure --prefix=/opt/ghc \ --with-ghc=/opt/ghc-bin/bin/ghc \ --with-gcc=/opt/gcc-vanilla/4.1.2/bin/gcc \ --with-gmp-includes=/opt/csw/include \ --with-gmp-libraries=/opt/csw/lib
Remember of course that you must use GNU make, not the system make. The Solaris 10 /usr/sfw/bin/gmake should do. Any other GNU make that you install from a third party repository should also be ok.
If you are lucky enough to have a box with lots of CPU cores then use them! Sadly the maximum number that it can actually use effectively is around 4. Hopefully the new build system in ghc-6.11 and later will be able to use more.
- link to expected testsuite results.
- how to make ghc use -R/opt/csw/lib for everything it builds (it get it into the rts pkg conifg)
- how to make sure it really does get built with readline support