January 2013 - ghc-devs

LLVM build not working?
by Stephen Paul Weber 25 Jan '13

25 Jan '13

I just tried my LLVM unregistered build again against HEAD (for QNX ARM) and got this: make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/. -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fllvm -no-user-package-db -rtsopts -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc30896_0/ghc30896_0.hc: In function 'c2pA_entry': /tmp/ghc30896_0/ghc30896_0.hc:3691:1: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] /tmp/ghc30896_0/ghc30896_0.hc:3691:17: error: expected ')' before numeric constant make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 You can clearly see that `-fllvm` *is* being passed, and I double-checked and I do have the quick-llvm build type selected... but it's trying via C? What? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

2 2

Darcs.haskell.org down again
by Simon Peyton-Jones 25 Jan '13

25 Jan '13

Ian, Paul It seems that 'abbott' is down again. Two days in a row suggests something is wrong. Is there anything either of you can do to help? Simon

4 4

-lrt and -lpthread order with static linking
by Anatoly Yakovenko 25 Jan '13

25 Jan '13

ghc places -lrt after -lpthread, causing pthread.a symbols to be missing when linking with -static and just for kicks it generates a .o in /tmp that it deletes on exit, so i cant relink. i think whoever added that owes me a beer. so in one shell i did a while true; do cp /tmp/*/*.o .; done and in another shell i ran the make command to grab that tmp file, then i was able to stick into the collect command i can grab from -optl--verbose and fully link the exe.

3 2

Stack smashing when using FunPtr wrappers on ARM
by Stephen Paul Weber 25 Jan '13

25 Jan '13

I just got my unregistered LLVM-based ARM cross-compiler to a working place, which means I can produce any binaries which do no crash. Yay! However, <http://hackage.haskell.org/trac/ghc/ticket/7621> when I try to use FunPtr wrappers, something smashes the stack. Would others working on ARM cross-compilers be willing to try this test and see if it works for you: {-# LANGUAGE ForeignFunctionInterface #-} module Main (main) where import Foreign.Ptr foreign import ccall "wrapper" wrap_refresh :: ( IO ()) -> IO (FunPtr ( IO ())) main :: IO () main = do wrap_refresh (return ()) return () -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

3 6

Today's validate failures
by Simon Marlow 25 Jan '13

25 Jan '13

Unexpected passes: perf/should_run T5113 (normal) Unexpected failures: cabal 1750 [bad stderr] (normal) cabal shadow [bad stderr] (normal) deriving/should_compile T1133 [bad exit code] (normal) deriving/should_fail T1133A [bad exit code] (normal) perf/haddock haddock.base [stat not good enough] (normal) polykinds T7594 [stderr mismatch] (normal) We know what the cabal failures are, and Simon PJ has said he'll be fixjng those. T1133 and T1133A look like a problem with spaces in pathnames: Stderr: make[3]: /home/simon/code-all/work/ghc-validate/bindisttest/install: Command not found make[3]: *** [T1133A] Error 127 *** unexpected failure for T1133A(normal) T7594 has been failing for a few days, I think: --- ./polykinds/T7594.stderr 2013-01-23 09:07:45.400727923 +0000 +++ ./polykinds/T7594.comp.stderr 2013-01-24 09:40:12.030265492 +0000 @@ -1,6 +1,3 @@ -h0 -h1 -h2 T7594.hs:25:11: Couldn't match type `b' with `IO ()' *** unexpected failure for T7594(normal)

3 3

ghc passing -undef to preprocessor and thereby eliminating OS specific defines
by Nathan Hüsken 24 Jan '13

24 Jan '13

Hey, I am trying to adapt some code in the libraries when compiling for android (i.E. because some things are different on android to other posix systems). So in C code I would just do "#ifdef __ANDROID__". While in the *.h and *.c files it seems to work, it does not work in *.hs files. I noted that the preprocessor is run like this: arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector -DTABLES_NEXT_TO_CODE The "-undef" parameter is causing the __ANDROID__ define to be removed. Does it make sense to pass "-undef" to the preprocessor? Any other Ideas how I could adapt the code for android? Thanks! Nathan

2 1

Mailing lists
by Ian Lynagh 24 Jan '13

24 Jan '13

Hi all, As you've probably noticed, the mailing list changes have now been made. The following new lists have been created: ghc-devs@ For developer discussions ghc-commits@ For automated commit messages from the git repositories ghc-builds@ For automated nightly build reports ghc-tickets@ For automated messages from trac These mailing lists no longer exist (but for now they forward to an appropriate new list): cvs-ghc@ cvs-libraries@ cvs-other@ glasgow-haskell-bugs@ People have been subscribed to the new lists based on which old lists they were on. If you find any web pages etc referring to the old lists, please ask the webmaster to update them (or do so yourself if e.g. it's on a wiki). Thanks Ian

2 1

Implementing primitive Bool operations
by Jan Stolarek 24 Jan '13

24 Jan '13

I want to work on implementing primitive Booleans in GHC and thus resolve trac ticket 6135 ( http://hackage.haskell.org/trac/ghc/ticket/6135 ). I haven't done any development work on GHC yet so this will be my first attempt to contribute something useful to the project. However, I need some help to get started. Right now my main problem is foreseeing consequences of introducing primitive booleans to the language. I gathered my thoughts on this subject on a wiki page ( http://hackage.haskell.org/trac/ghc/wiki/PrimBool ). I see some things that can go wrong with solutions I came up with so far. I will appreciate if someone with more knowledge could comment on them and help me decide on which approach to implementing primitive Bool should I take. Janek

1 0

Strange GNU make behavior/why are not shared libs built on Solaris?
by Karel Gardas 23 Jan '13

23 Jan '13

Hello, before making a ticket for this, I'm curious why are not shared libs build on Solaris 11 on GHC HEAD. Please note 7.6.1 release is not affected by this and shared libs are build on Solaris well (using the exactly same environment). I've tried to debug a little bit makefile machinery and the results are confusing: $ gmake show VALUE=PlatformSupportsSharedLibs gmake -r --no-print-directory -f ghc.mk show PlatformSupportsSharedLibs="YES" so here, everything is fine, Solaris is supported for shared libs (i.e. there is no broken ld presented on Solaris 11 which would disable this feature). Now: $ gmake show VALUE=GhcLibWays gmake -r --no-print-directory -f ghc.mk show GhcLibWays="v" why is that, when the code in mk/config.mk is clear enough and contains: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif ? Am I just simply blind and don't see obvious fact or is that really confusing behavior? BTW: Solaris 11 provided GNU make 3.81, that's what I'm using. Thanks a lot for any idea how to debug this further! Karel

2 2

Abott down?
by Simon Peyton-Jones 22 Jan '13

22 Jan '13

Is abbott (darcs.haskell.org) down? http://www.downforeveryoneorjustme.com/darcs.haskell.org says it is, and I can't access it. Urk. Simon

3 5