Re: ghc 4.02 compilation failure (linux i386 glibc)
On Wed, May 26, 1999 at 11:18:34AM +0100, Giuliano P Procida wrote: > I will try to hack hsc with a binary editor to remove the fflush > call and see what happens. OK, one hacked hsc and a couple more hours of compilation later and I've run into another problem (compiling ghc/lib/posix/PosixTTY.lhs). The last few lines of the build log are: /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/cc1 /tmp/ccWi8YKZ.i -quiet -dumpbase ghc5854.c -O -Wimplicit -version -fomit-frame-pointer -fno-defer-pop -o ghc5854.s GNU C version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) (i486-linux) compiled by GNU C version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release). Epilogue junk?: popl %ecx .Lfe337: .sizec91T_ret,.Lfe337-c91T_ret .section.rodata .align 4 .typec91S_info,@object .sizec91S_info,12 make[3]: *** [PosixTTY.o] Error 2 Further details on request. Giuliano. -- [EMAIL PROTECTED]
RE: GHC doesn't understand a .hi file
> I think it's a bug when a compiler doesn't
> understand an intermediate file it generated a
> few minutes before. According to GHC:
It's a bug all right. I've just fixed it. In principle there
is absolutely nothing wrong with types like
zdfHasTextWindow :: __forall [v]
{GUIValue.GUIValue v, GUIState.GUIObject
Window} =>
{GUIBaseClasses.HasText Window v}
but at the moment GHC doesn't let you write them. This one
arose because (I think) you had something like
class GUIObject w => HasText w v where ...
instance GUIValue v => HasText Window v where ...
The dictionary function arising from the instance decl takes
no only the GUIValue v dictionary, but also the superclasses
of HasText, in this case (GUIObject Window); but since the latter
is constant there's no point in passing it.
If you update your compiler later today you should get the
new code (it's in mkDictFunId in MkId.lhs).
Thanks for reporting it.
Simon
Re: ghc 4.02 compilation failure (linux i386 glibc)
On Tue, May 25, 1999 at 02:08:19PM +0100, I wrote: > However, it may have been a miscompiled glibc (this is the > libc6-2.1.1-7 Debian build), more news tomorrow when I find the > relevant mail messages. It still does not work with the 2.1.1-9 build, so it may have been something introduced since libHS was built, or it may be a compiler problem. I will try to hack hsc with a binary editor to remove the fflush call and see what happens. Giuliano.
Re: GHC doesn't understand a .hi file
> Line 114 of Window.hi says:
> > 1 zdfHasTextWindow :: __forall [v] {GUIValue.GUIValue v, GUIState.GUIObject
>Window} => {GUIBaseClasses.HasText Window v} ;
>
> ghc --version says
> > The Glorious Glasgow Haskell Compilation System, version 4.03, patchlevel 0
> I downloaded it around 18th May from the CVS repository and compiled it
> for sparc-solaris.
On the 11th May the .hi format changed from what you have above,
slightly; this shouldn't cause the problem you mention but it does mean
that your ghc is older than you think. It should look like this:
> 1 zdfHasTextWindow :: __forall [v] => {GUIValue.GUIValue v} -> {GUIState.GUIObject
>Window} -> {GUIBaseClasses.HasText Window v} ;
HTH.
--KW 8-)
--
: Keith Wansbrough, MSc, BSc(Hons) (Auckland) :
: PhD Student, Computer Laboratory, University of Cambridge, England. :
: (and recently of the University of Glasgow, Scotland. [><] ) :
: Native of Antipodean Auckland, New Zealand: 174d47' E, 36d55' S.:
: http://www.cl.cam.ac.uk/users/kw217/ mailto:[EMAIL PROTECTED] :
:-:
