ghc haskell compiler

[Goetz Isenmann]

Ok, as promised yesterday on #dragonflybsd, I tried to build ghc-7.0.4
on both 32bit and 64bit DragonFly.

Since I was not able to spend much time on this, I just run the build
on the available machines with their current setup, and took the
results without much testing. See below for possible problems.

========================================================================

For i386 you need (sorry, you have to use exactly those URLs; no
access to the dfly directory):

  http://www.goetz-isenmann.de/dfly/errno_ptr-i386.DragonFly-2.10.tar.xz
  http://www.goetz-isenmann.de/dfly/ghc-7.0.4-i386.DragonFly-2.10.tar.xz
  http://www.goetz-isenmann.de/dfly/cabal-i386.DragonFly-2.10.xz

For x86_64:

  http://www.goetz-isenmann.de/dfly/errno_ptr-x86_64.DragonFly-2.13.tar.xz
  http://www.goetz-isenmann.de/dfly/ghc-7.0.4-x86_64.DragonFly-2.13.tar.xz
  http://www.goetz-isenmann.de/dfly/cabal-x86_64.DragonFly-2.13.xz

The sources are:

  http://www.goetz-isenmann.de/dfly/errno_ptr.tar.xz
  http://www.goetz-isenmann.de/dfly/ghc-7.0.4-patches.tar.xz

Both errno_ptr-<arch>.tar.xz and ghc-7.0.4-<arch>.tar.xz should be
extracted below /usr/local.

The cabal-<arch>.xz ist a cabal(-install) binary built with above
compilers, for easier installation of further libraries.

========================================================================

Possible problems:

 1. Since I have this errno_ptr stuff also below /usr/pkg, the build
    process might have picked those, and you need to move them there
    or set LD_LIBRARY_PATH and maybe also use (3).
 2. I am not sure, what the configure script found on both machines,
    and the result might depend on different sets and versions of
    shared libraries like libiconv and libgmp.
 3. You probably have to set "extra-include-dirs: /usr/pkg/include"
    and "extra-lib-dirs: /usr/pkg/lib" in $HOME/.cabal/config or
    use similar commandline arguments to build stuff using native
    code.

Please tell me, if there are other problems, or if I could help with
doing the build differently.

========================================================================

Maybe a few words about the porting. The 32bit port was very easy,
since DragonFly at this time was able to execute FreeBSD4 binaries.

Porting was merely a searching for every "defined(__FreeBSD__)" and
appending a " || defined(__DragonFly__)", with one exception, where I
have only a workaround but not real solution until now.

The ghc compiler creates object files for a static executable, but has
also a simple Linker (rts/Linker.c) that can load those object files
at runtime. This is neccessary for the interactive ghci and for
Template Haskell (not much fun without). This linker can only handle
the most common relocations, and is not able to load anything that
accesses our "extern __thread int errno;".

I have put some (limited) time into trying to understand how this
thread local storage stuff works, but decided to go with this
workaround:
Put the function "int *errno_ptr(void) { return (&errno); }" into a
shared library "liberrno_ptr" and patch the ghc sources to replace the
errno access with calling this function.

The 64bit port took much more time and was frustrating, but also very
easy looking back afterwards.

At first I used dfly/i386 to bootstrap x86_64, and succeeded with the
build after only some small fixes to the documented bootstrap process.
But the compiler crashed immediately during initialization. It took me
some time to notice that it was a general problem, that the
bootstraped compiler used only 32bit of pointers for native calls from
Haskell to C.

Since I saw no simple way, to fix this with my level of "knowledge"
about the generated code, I decided to try FreeBSD/amd64 next.

The build succeeded following the same steps as before. The result was
a little better but was totally confused about the file system because
"struct stat" on FreeBSD and DragonFly differ.

Took some time to understand the generated code, but then it was
enought (as far as I remember) to change a single bit shift value at
only one place, to get a compile that was able to do the bootstrap
(probably not much more).

========================================================================

Have still no good idea, how to integrate this into pkgsrc. Have also
not seen a good place to integrate this errno access wrapper into a
patch against the ghc sources only.

So if you have a good idea, or even better if you know how to fix the
rts/Linker.c problem with this "unhandled ELF relocation(Rel) type 15"
please let me/us know...

--
Goetz