
"Goetz" == Goetz Isenmann
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