|
|
# 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.
|
|
|
These instructions have only been checked for GHC 6.12.1 on Solaris 10 on SPARC. It should mostly apply to later versions of GHC, Solaris 8 and later and perhaps Solaris on x86.
|
|
|
|
|
|
|
|
|
A common theme in these instructions is the issue that required tools and libraries are not part of the standard system set and the need for us to set various flags to tell the build system where to find them. For the sake of being concrete, the instructions below use the example of packages from the [ blastwave.org](http://www.blastwave.org/) collection which get installed under the `/opt/csw` prefix. You can substitute your own path (or paths) as appropriate to your system.
|
|
|
A common theme in these instructions is the issue that required tools and libraries are not part of the standard system set and the need for us to set various flags to tell the build system where to find them.
|
|
|
|
|
|
## Using a bootstrapping GHC
|
|
|
## Installing GNU packages
|
|
|
|
|
|
|
|
|
You can either get the binary from the ghc download page or use some other pre-existing ghc binary.
|
|
|
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).
|
|
|
|
|
|
> <table><tr><th> GNU binutils 2.20 </th>
|
|
|
> <th> for GNU ld, maybe others
|
|
|
> </th></tr>
|
|
|
> <tr><th> GNU coreutils 8.4 </th>
|
|
|
> <th> for GNU tr, maybe others
|
|
|
> </th></tr>
|
|
|
> <tr><th> GNU make 3.81 </th>
|
|
|
> <th> make files use GNU extensions
|
|
|
> </th></tr>
|
|
|
> <tr><th> GNU m4 1.4.13 </th>
|
|
|
> <th></th></tr>
|
|
|
> <tr><th> GNU sed 4.2 </th>
|
|
|
> <th> build scripts use GNU extensions
|
|
|
> </th></tr>
|
|
|
> <tr><th> GNU tar 1.20 </th>
|
|
|
> <th> Solaris tar doesn't handle large file names
|
|
|
> </th></tr>
|
|
|
> <tr><th> GNU grep 2.5 </th>
|
|
|
> <th> build scripts use GNU extensions
|
|
|
> </th></tr>
|
|
|
> <tr><th> GNU readline 5 </th>
|
|
|
> <th></th></tr>
|
|
|
> <tr><th> GNU ncurses 5.5 </th>
|
|
|
> <th></th></tr>
|
|
|
> <tr><th> Python 2.6.4 </th>
|
|
|
> <th></th></tr>
|
|
|
> <tr><th> GCC 4.1.2 </th>
|
|
|
> <th> this exact version is needed
|
|
|
> </th></tr></table>
|
|
|
|
|
|
The binary from the ghc download page depends on `gmp`, `readline` and `ncurses`, none of which are on the default runtime linker search path. It is necessary therefore to set the `LD_LIBRARY_PATH`, either in the ghc driver shell script or in the environment while doing the build. The latter is simpler:
|
|
|
|
|
|
```wiki
|
|
|
export LD_LIBRARY_PATH=/opt/csw/lib
|
|
|
```
|
|
|
Some of these can be obtained as binary versions from the [ blastwave.org](http://www.blastwave.org/) collection, others need to be downloaded as source from [ gnu.org](http://www.gnu.org).
|
|
|
|
|
|
|
|
|
Note: part of the aim of these instructions is to build a ghc that will not require the use of `LD_LIBRARY_PATH`. That is, it should not be required to run ghc itself, or any of the programs built by ghc. This is appropriate for installing on a single machine or a set of identically configured machine, or for a binary package collection. However this is not appropriate if you are trying to build a generic, relocatable, redistributable binary package. In that case you do not want to hard code the location of libraries or programs and the user of the package will have to set their `$PATH` and `LD_LIBRARY_PATH` appropriately. The differences are noted below.
|
|
|
The blastwave libraries are usually installed under `/opt/csw`, so you may need to manually set `LD_LIBRARY_PATH` to point to them:
|
|
|
|
|
|
```wiki
|
|
|
export LD_LIBRARY_PATH=/opt/csw/lib
|
|
|
```
|
|
|
|
|
|
In the example below we will assume that the bootstrapping ghc is installed in `/opt/ghc-bin` and that our final ghc will be installed to `/opt/ghc`.
|
|
|
|
|
|
## Using the right GCC
|
|
|
|
|
|
### Avoid the system GCC versions
|
|
|
## Using a bootstrapping GHC
|
|
|
|
|
|
|
|
|
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.
|
|
|
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 `/usr/sfw/bin/gcc` version (at least on Solaris 10) is 3.4.x which is reported to have problems, see below.
|
|
|
|
|
|
The rest of this page lists problems with specific tool versions. If you stick to the versions in the above list then you shouldn't have to read further.
|
|
|
|
|
|
It is recommended therefore to install another gcc package, either from some Solaris binary package or to build a vanilla gcc from source.
|
|
|
## Only some GCC versions work
|
|
|
|
|
|
### Selecting a good GCC version
|
|
|
- GCC version 4.1.2 is known to work. Use this version if possible.
|
|
|
|
|
|
|
|
|
GHC only works with particular GCC versions.
|
|
|
On Solaris 10, `/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 (mangle) the assembly output of GCC. It expects the format and layout that the normal GCC uses.
|
|
|
|
|
|
|
|
|
For compiling GHC 6.10.1, GCC versions 4.0.4 and 4.1.2 are known to work. Others in the 4.0.x and 4.1.x series may work, but haven't been tested.
|
|
|
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.
|
... | ... | @@ -58,32 +84,6 @@ GCC version 4.0.2 does not support thread local state (TLS), at least on SPARC. |
|
|
GCC version 3.4.x is reported ([\#951](https://gitlab.haskell.org//ghc/ghc/issues/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.
|
|
|
|
|
|
## 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](https://gitlab.haskell.org//ghc/ghc/issues/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.
|
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
```wiki
|
|
|
export PATH=/opt/gcc-vanilla/bin:$PATH
|
|
|
./configure --with-gcc=/opt/gcc-vanilla/4.1.2/bin/gcc
|
|
|
```
|
|
|
|
|
|
|
|
|
Of course, if you are building a relocatable binary package then it makes sense to omit the `--with-gcc=` flag (with an exotic path) and leave it to the user to ensure the proper `gcc` is found via the $PATH\`.
|
|
|
|
|
|
## Fixing the `unix` package
|
|
|
|
|
|
|
|
|
At the time of writing the `unix` package gets built wrong (see [\#2969](https://gitlab.haskell.org//ghc/ghc/issues/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 from a non-standard location
|
|
|
|
|
|
|
... | ... | |