Simon, it looks like I'm running into problems similar to those Edsko
described in the email "Top-level type signatures in TcGblEnv?" to
ghc-devs a while ago. The complete information about a source file is
spread out over several different ASTs.
___
ghc
On Thu, Apr 4, 2013 at 1:44 AM, Simon Peyton-Jones
wrote:
> I would be very surprised if nameModule_maybe returned Nothing for a Name
> that printed with its module name. Yet it appears that you are saying that
> a Name that prints with its module name with -ddump-ds or -ddump-tc
>
This patch disables shared libs support on arm-unknown-linux platform. It
unbreaks ghc-stage2 on this platform after recent Ian's changes
in dynamic/shared libs domain. The reason why ghc-stage2 fails when linked
with shared libs is still unknown so this is just a workaround at the moment,
but it a
---
mk/config.mk.in |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/mk/config.mk.in b/mk/config.mk.in
index 275c21a..de55f0d 100644
--- a/mk/config.mk.in
+++ b/mk/config.mk.in
@@ -135,8 +135,12 @@ ifeq "$(TargetOS_CPP)" "mingw32"
# This doesn't work on Windows yet
DYN
I'm not sure the use case being discussed here is really what I'm after. This
use case has a type family application appearing within a forall
> Maybe (forall a. F [a]) ...
This actually seems to work OK when I test it, though I haven't looked closely
at the internal machinery.
I'm more concer
| I understand that. I think it's unrelated to my problem however.
| moduleName_maybe, the function that's supposed to give me the module
| of a Name returns Nothing for all locally defined names. My guess is
| that these Names aren't made fully qualified until some later stage.
I think there
From: Gabor Greif
Subject: Linker error in stage2
Date: Wed, 3 Apr 2013 11:42:08 +0200
> I am getting linker errors when bootstrapping HEAD with a recent
> v7.7-20130220 GHC. This is a RHEL5 system:
>
> "inplace/bin/ghc-stage1" -package-name rts -shared -dynamic -dynload
> deploy -no-auto-link-pa
