Porting to DragonFly BSD

[Colin Paul Adams]

>>>>> "Goetz" == Goetz Isenmann <info at goetz-isenmann.de> writes:


    Goetz> Until now I had no time and energie to dig deeper into the
    Goetz> problem [1], that looks to me, like rts/Linker cannot load
    Goetz> any object file that references errno.

    Goetz> My guess is, that for dragonflys "extern __thread int
    Goetz> errno;" we do not only need to add a new case in
    Goetz> rts/Linker.c but also need to generate different code for
    Goetz> this thread local storage access.


    Goetz> [1] $ ghci GHCi, version 6.10.4:
    Goetz> http://www.haskell.org/ghc/ :? for help Loading package
    Goetz> ghc-prim ... linking ... done.  Loading package integer
    Goetz> ... linking ... done.  ghc:
    Goetz> /var/tmp/isenmann/ghc-6.10.4-3/lib/ghc-6.10.4/base-4.1.0.0/HSbase-4.1.0.0.o:
    Goetz> unhandled ELF relocation(Rel) type 15

    Goetz> Loading package base ... linking ... ghc: unable to load
    Goetz> package `base'

After some googling, and learning very little, I speclated that simply
adding a third line for R_386_TLS_IE with the same action as the first
line - just storing value, might work: 

case R_386_TLS_IE: *pP = value; break;

This seems to work up to a point. That is I get no crashes in ghci.

I do appear to have some line-feed problems. So if I type:

Prelude> let x = 10

It appears to do nothing, but that is not the case - I can then
overtype with :t x and ghci responds with:

x :: Integerxx = 10
Prelude>

So maybe this is a readline/haskelline issue?

I then tried a cabal install of my website application. This fails,
but I think it is because I need to apply various patches to haskelldb
modules that are not yet in hackage.
-- 
Colin Adams
Preston Lancashire