Re: HEADS UP: New primops in HEAD
Any idea what this could be? Yes, it looks like http://ghc.haskell.org/trac/ghc/ticket/8320 This ticket was reported about 20 hours *before* I pushed my patches. I also think that I've seen someone reporting this problem earlier, but I can't find anything on the list or lpaste, so perhaps I'm wrong here (or maybe I've seen it myself?). Anyway, were my patches the only ones that you pulled? Or did you pull some others as well? I've seen that there were some commits pushed to haddock repo just before you sent your mail - have you done your build with or without them? Janek - Oryginalna wiadomość - Od: Gabor Greif ggr...@gmail.com Do: Jan Stolarek jan.stola...@p.lodz.pl DW: ghc-devs ghc-devs@haskell.org Wysłane: środa, 18 wrzesień 2013 22:39:43 Temat: Re: HEADS UP: New primops in HEAD On 9/18/13, Jan Stolarek jan.stola...@p.lodz.pl wrote: New comparison primops are now in HEAD. This change breaks backwards compatibility for comparison primops. What you need to do after pulling the latest HEAD is: 1) Upgrade to latest versions of Alex and Happy (cabal update cabal install alex happy). With your recipe I was able to build GHC. But I got this: make -r --no-print-directory -f ghc.mk phase=final all /Users/ggreif/ghc-head/inplace/bin/haddock --odir=libraries/ghc-prim/dist-install/doc/html/ghc-prim --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title=ghc-prim-0.3.1.0: GHC primitives --prologue=libraries/ghc-prim/dist-install/haddock-prologue.txt --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: Warning: Couldn't find .haddock for export GHC.Prim.Int64# Warning: Couldn't find .haddock for export GHC.Prim.Word64# 3% ( 1 / 38) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /354) in 'GHC.PrimopWrappers' 33% (181 /553) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' attempting to use module 'ghc-prim:GHC.Types' (libraries/ghc-prim/./GHC/Types.hs) which is not loaded make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make[1]: Target `all' not remade because of errors. make: *** [all] Error 2 make: Target `default' not remade because of errors. Any idea what this could be? Anyway, using `make --keep-going` I was able to install (almost) everything, and it looks good. Cheers, Gabor 2) Rebase your branches on top of HEAD, if these branches were in a repository affected by primop change. Repositories that will were affected: GHC, testsuite, array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, template-haskell. 3) Blow away your build. Be sure to run ./configure to pick up new versions of Alex and Happy Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: HEADS UP: New primops in HEAD
On 9/19/13, Jan Stolarek jan.stola...@p.lodz.pl wrote: Any idea what this could be? Yes, it looks like http://ghc.haskell.org/trac/ghc/ticket/8320 Yeah, this seems to be it. This ticket was reported about 20 hours *before* I pushed my patches. I also Then it must be an unrelated problem, good :-) think that I've seen someone reporting this problem earlier, but I can't find anything on the list or lpaste, so perhaps I'm wrong here (or maybe I've seen it myself?). Anyway, were my patches the only ones that you pulled? Or did you pull some others as well? I've seen that there were some I pulled everything *up to* your patches. I had an (essentially) clean workspace. commits pushed to haddock repo just before you sent your mail - have you done your build with or without them? Originally I did not have those, later pulled them too, but it did not change the situation. I'll watch the PR you have given. Cheers, Gabor Janek - Oryginalna wiadomość - Od: Gabor Greif ggr...@gmail.com Do: Jan Stolarek jan.stola...@p.lodz.pl DW: ghc-devs ghc-devs@haskell.org Wysłane: środa, 18 wrzesień 2013 22:39:43 Temat: Re: HEADS UP: New primops in HEAD On 9/18/13, Jan Stolarek jan.stola...@p.lodz.pl wrote: New comparison primops are now in HEAD. This change breaks backwards compatibility for comparison primops. What you need to do after pulling the latest HEAD is: 1) Upgrade to latest versions of Alex and Happy (cabal update cabal install alex happy). With your recipe I was able to build GHC. But I got this: make -r --no-print-directory -f ghc.mk phase=final all /Users/ggreif/ghc-head/inplace/bin/haddock --odir=libraries/ghc-prim/dist-install/doc/html/ghc-prim --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title=ghc-prim-0.3.1.0: GHC primitives --prologue=libraries/ghc-prim/dist-install/haddock-prologue.txt --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-H32m --optghc=-O --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: Warning: Couldn't find .haddock for export GHC.Prim.Int64# Warning: Couldn't find .haddock for export GHC.Prim.Word64# 3% ( 1 / 38) in 'GHC.IntWord64' 80% ( 8 / 10) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /354) in 'GHC.PrimopWrappers' 33% (181 /553) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' attempting to use module 'ghc-prim:GHC.Types' (libraries/ghc-prim/./GHC/Types.hs) which is not loaded make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make[1]: Target `all' not remade because of errors. make: *** [all] Error 2 make: Target `default' not remade because of errors. Any idea what this could be? Anyway, using `make --keep-going` I was able to install (almost) everything, and it looks good. Cheers, Gabor 2) Rebase your branches on top of HEAD, if these branches were in a repository affected by primop change. Repositories that will were affected: GHC, testsuite, array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, template-haskell. 3) Blow away your build. Be sure to run ./configure to pick up new versions of Alex and Happy Janek ___ ghc-devs mailing list ghc-devs@haskell.org
Testsuite with profiling
I need to run testsuite with profiling turned on. When I run make WAY=normal EXTRA_HC_OPTS=-prof -fprof-auto -rtsopts lots of tests are failing with: Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the dynamic way, and then in the desired way using -osuf to set the object file suffix. I only added GhcLibWays += p to quick section of my build.mk. I guess this error message has something to do with DYNAMIC_BY_DEFAULT - I could probably get this right with a trial and error approach, but I'd rather know what I'm doing. Can anyone tell me what is going on and what do I need to do to make this work? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: recomp013
Simon, I think you didn't paste the failure. Janek - Oryginalna wiadomość - Od: Simon Peyton-Jones simo...@microsoft.com Do: ghc-devs@haskell.org, Joachim Breitner m...@joachim-breitner.de Wysłane: czwartek, 19 wrzesień 2013 12:17:29 Temat: recomp013 I’m getting the failure below for recomp013. Any ideas? It was added by Joachim: commit b1f6cab360faf79d586eda8ee3c1c486e53d0066 Author: Joachim Breitner m...@joachim-breitner.de Date: Tue Sep 17 22:37:51 2013 +0200 Recompilation test case for #8247 Joachim: when you have a test for a ticket, please use “T8247” as the test name. Much easier to track back! Thanks. Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: recomp013
Sorry, here = recomp013(normal) 89 of 114 [0, 0, 0] cd ./recomp013 $MAKE -s --no-print-directory recomp013/dev/null recomp013.run.stdout 2recomp013.run.stderr Actual stdout output differs from expected: --- ./recomp013/recomp013.stdout2013-09-18 12:38:22.0 +0100 +++ ./recomp013/recomp013.run.stdout2013-09-19 12:15:22.611120935 +0100 @@ -3,5 +3,3 @@ [2 of 3] Compiling B( B.hs, B.o ) [3 of 3] Compiling C( C.hs, C.o ) second run -[2 of 3] Compiling B( B.hs, B.o ) -[3 of 3] Compiling C( C.hs, C.o ) [B changed] *** unexpected failure for recomp013(normal) | -Original Message- | From: Jan Stolarek [mailto:jan.stola...@p.lodz.pl] | Sent: 19 September 2013 12:22 | To: Simon Peyton-Jones | Cc: ghc-devs@haskell.org; Joachim Breitner | Subject: Re: recomp013 | | Simon, I think you didn't paste the failure. | | Janek | | - Oryginalna wiadomość - | Od: Simon Peyton-Jones simo...@microsoft.com | Do: ghc-devs@haskell.org, Joachim Breitner m...@joachim-breitner.de | Wysłane: czwartek, 19 wrzesień 2013 12:17:29 | Temat: recomp013 | | | | I’m getting the failure below for recomp013. Any ideas? It was added by | Joachim: | | | | commit b1f6cab360faf79d586eda8ee3c1c486e53d0066 | | Author: Joachim Breitner m...@joachim-breitner.de | | Date: Tue Sep 17 22:37:51 2013 +0200 | | | | Recompilation test case for #8247 | | | | Joachim: when you have a test for a ticket, please use “T8247” as the | test name. Much easier to track back! Thanks. | | | | Simon | | | | | | Microsoft Research Limited (company number 03369488) is registered in | England and Wales | | Registered office is at 21 Station Road, Cambridge, CB1 2FB | | | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: recomp013
Dear Simon, Am Donnerstag, den 19.09.2013, 11:33 + schrieb Simon Peyton-Jones: = recomp013(normal) 89 of 114 [0, 0, 0] cd ./recomp013 $MAKE -s --no-print-directory recomp013/dev/null recomp013.run.stdout 2recomp013.run.stderr Actual stdout output differs from expected: --- ./recomp013/recomp013.stdout 2013-09-18 12:38:22.0 +0100 +++ ./recomp013/recomp013.run.stdout 2013-09-19 12:15:22.611120935 +0100 @@ -3,5 +3,3 @@ [2 of 3] Compiling B( B.hs, B.o ) [3 of 3] Compiling C( C.hs, C.o ) second run -[2 of 3] Compiling B( B.hs, B.o ) -[3 of 3] Compiling C( C.hs, C.o ) [B changed] *** unexpected failure for recomp013(normal) It works here. So that means either two things: * that the bug described in #8247 is actually present in HEAD, but only under certain circumstances, or * that there is a timing issue with the update of B.hs. The latter seems to be more likely. I notice that other recomp-tests have a sleep 1 before updating the file: If you insert that in recomp013/Makefile, does it go through for you? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: recomp013
that makes it work.! | -Original Message- | From: Joachim Breitner [mailto:m...@joachim-breitner.de] | Sent: 19 September 2013 12:41 | To: Simon Peyton-Jones; ghc-devs@haskell.org | Subject: Re: recomp013 | | Dear Simon, | | Am Donnerstag, den 19.09.2013, 11:33 + schrieb Simon Peyton-Jones: | = recomp013(normal) 89 of 114 [0, 0, 0] | cd ./recomp013 $MAKE -s --no-print-directory recomp013 | /dev/null recomp013.run.stdout 2recomp013.run.stderr | Actual stdout output differs from expected: | --- ./recomp013/recomp013.stdout2013-09-18 12:38:22.0 +0100 | +++ ./recomp013/recomp013.run.stdout2013-09-19 12:15:22.611120935 | +0100 | @@ -3,5 +3,3 @@ | [2 of 3] Compiling B( B.hs, B.o ) | [3 of 3] Compiling C( C.hs, C.o ) | second run | -[2 of 3] Compiling B( B.hs, B.o ) | -[3 of 3] Compiling C( C.hs, C.o ) [B changed] | *** unexpected failure for recomp013(normal) | | It works here. So that means either two things: | * that the bug described in #8247 is actually present in HEAD, but |only under certain circumstances, or | * that there is a timing issue with the update of B.hs. | | The latter seems to be more likely. I notice that other recomp-tests | have a sleep 1 before updating the file: If you insert that in | recomp013/Makefile, does it go through for you? | | Greetings, | Joachim | | -- | Joachim “nomeata” Breitner | m...@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C | Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: primitive using PrimWrappers rather than PrimOpWrappers?
Hey jan, I seem to have sorted it out. There's still some dirty module state, but nothing that's a blocker. If I hit it again today ill be sure to holler. Thanks! Carter On Thursday, September 19, 2013, Jan Stolarek wrote: As Gabor pointed out, this sounds like problems with rebasing on top of my patches. Carter, have you managed to resolve this? If not then please let me know - I'll try to help. Janek - Oryginalna wiadomość - Od: Gabor Greif ggr...@gmail.com javascript:; Do: Carter Schonwald carter.schonw...@gmail.com javascript:; DW: ghc-devs@haskell.org javascript:; Wysłane: środa, 18 wrzesień 2013 23:50:48 Temat: Re: primitive using PrimWrappers rather than PrimOpWrappers? $ git pull --rebase just pulls and then rebases your local commits. It gives up (with an error message) if there are unstaged changes in the workspace. On 9/19/13, Carter Schonwald carter.schonw...@gmail.com javascript:; wrote: what does the rebase flag do? I did my rebase via the sourcetree gui app.. On Wed, Sep 18, 2013 at 6:40 PM, Gabor Greif ggr...@gmail.comjavascript:; wrote: I had the same error, turned out that ./sync-all pull --rebase did not correctly terminate, because I had modified files around This helped: ./sync-all pull perl boot ./configure make --keep-going HTH, Gabor On 9/19/13, Carter Schonwald carter.schonw...@gmail.com javascript:; wrote: hey all, i just rebased my prefetch patch onto HEAD, and now i'm working on getting ghc to build looks like Data.Primitive.Types is trying to import PrimWrappers rather than PrimOpWrappers? i patched that up in my local build, but that seems to be missing, unless i'm overlooking somthing and i'm botching the submodules? ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: llvm calling convention matters
If you pass a constant, unboxed value to a primop, I assume GHC won't ever bind the argument to a value. So although we have no way to enforce static const argument in the type system, if this is a valuable (and experts-only?) operation, I'm not sure it matters that much if the user gets an error at code-generation time complaining about non-const arguments. Another way to look at it: if we wait until someone enhances the type system to support the notion of static arguments, we will likely never have a bit shuffle primitive. The other option would be to fall back on a different implementation if we saw a non-constant argument. I think that would actually be worse than erroring out, but I'm sure others would disagree. Geoff On 09/19/2013 11:42 AM, Carter Schonwald wrote: tldr; we can't express / expose the LLVM shuffleVector intrinsic in a type safe way that will correctly interact with the static argument requirement for associated code generation. On Thu, Sep 19, 2013 at 12:40 AM, Carter Schonwald carter.schonw...@gmail.com mailto:carter.schonw...@gmail.com wrote: yup, i hit a gap in what we can currently express in haskell types. We don't have a way of expressing static data! I actually put ticket on trac noting this. http://ghc.haskell.org/trac/ghc/ticket/8107 (note that when i was initially writing the ticket, i incorrectly thought the int# arg to ghc's prefetch was the locality level rather than a byte offset) Currently GHC has no way of expressing this argument needs to be a static compile/codegen time constant in surface haskell or core! This means we could at best provide a suite of special cased operations. (eg: we could provide the inter-lane shuffle for swapping halves of YMM registers, and the miniature analogue for XMM), but that would really be missing the point: being able to write complex algorithms that can work completely in registers! the vast majority of the simd shuffle operations have certain arguments that need to be compile time static values that are used in the actual code generation. The llvm data model doesn't express this constraint. This invariant failure was also hit internally recently via a bug in how GHC generated code for llvm's memcopy! http://ghc.haskell.org/trac/ghc/ticket/8131 If we could express llvm'sshuffleVector http://llvm.org/docs/LangRef.html#shufflevector-instruction intrinsic in a type safe way, then we could express any of them. I would be over the moon if we could expose an operation like shuffleVector, but I dont' think GHC currently can express it in a type safe way that won't make LLVM vomit. I want simd shuffle, but i don't see how to give the fully general shuffle operations in type safe ways with ghc currently. We need to add support for some notion of static data first! If theres a way, i'm all for it, but I don't see such a way. I hope that answers your question. that seems to be a deep enough issue that theres no way to resolve it with simple engineering in the next few weeks. -Carter On Wed, Sep 18, 2013 at 9:41 PM, Geoffrey Mainland mainl...@apeiron.net mailto:mainl...@apeiron.net wrote: On 09/18/2013 04:49 PM, Carter Schonwald wrote: I've some thoughts on how to have a better solution, but they are feasible only on a time scale suitable for 7.10, and not for 7.8. a hacky solution we could do for 7.8 perhaps is have a warning that works as follows: either a) throw a warning on functions that use the SIMD primops, if that function is being exported by a module, and that function isn't marked NOINLINE ? Theres probably a few subtleties to it, and this is just a naive idea That wouldn't inform the consumers of a module. And for a library like vector, we definitely want to export unfoldings for code that contains SIMD primops. That's the only way to get good code out of the library! b) somehow put both the -fllvm and -fasm core for inlineable functions in the .hi file? (this one prevents the most problems, but is probably the most complex work around we could do). The problem being that there *is* no -fasm code...because the NCG doesn't support SIMD operations. Unless we added a mechanism to have two completely different, but simultaneous, definitions for a function, one for -fasm and one for -fllvm. But that would be a lot of work and couldn't be done for 7.8. its worth noting that the LLVM simd in 7.8, either way, won't support simd shuffles, which will
Re: Testsuite with profiling
That's to be expected, because unfortunately, profiling is not a transparent operation; you have to compile things differently and certain features don't work. You might have better luck doing a slow test run, with WAY=prof (there are actually a number of other cases too, such as prof_hc_hb, etc, see testsuite/config/ghc) Edward Excerpts from Jan Stolarek's message of Thu Sep 19 02:30:53 -0700 2013: I need to run testsuite with profiling turned on. When I run make WAY=normal EXTRA_HC_OPTS=-prof -fprof-auto -rtsopts lots of tests are failing with: Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the dynamic way, and then in the desired way using -osuf to set the object file suffix. I only added GhcLibWays += p to quick section of my build.mk. I guess this error message has something to do with DYNAMIC_BY_DEFAULT - I could probably get this right with a trial and error approach, but I'd rather know what I'm doing. Can anyone tell me what is going on and what do I need to do to make this work? Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
