On Tue, Dec 01, 1998 at 12:01:20AM -0800, Sigbjorn Finne (Intl Vendor) wrote:
> Instead of the relevant #error in includes/StgTypes.h,
> try inserting
>
> typedef unsigned long StgNat64;
> typedef signed long StgInt64;
>
> and have another go..
Actually, its in the long long support, but
> Is it within the realms of possibility that you're using Sun's Yacc, and
> not bison here?
Very much so, it would seem.
> The relevant configure script feature test isn't that
> picky about what ilk of Yacc it chooses
To sat the least! On a system that has both, it appears that configure
w
> > The relevant configure script feature test isn't that
> > picky about what ilk of Yacc it chooses
>
> To sat the least! On a system that has both, it appears that
> configure went out of its way to pick "yacc".
>
Odd, the implementation of the (std) AC_PROG_YACC feature test
does look f
Hello!
On Tue, Dec 01, 1998 at 10:25:36AM -0800, Sigbjorn Finne (Intl Vendor) wrote:
> Try to create a fresh source tree, since it looks as if you've
> got "old" sources hanging about in yours (i.e., Literal is no
> more, it's Const these days.)
I'll try that. But I thought, even if I have a st
Felix Schroeter <[EMAIL PROTECTED]> writes:
>
> > Try to create a fresh source tree, since it looks as if you've
> > got "old" sources hanging about in yours (i.e., Literal is no
> > more, it's Const these days.)
>
> I'll try that. But I thought, even if I have a stale source file,
> the Makef
Try to create a fresh source tree, since it looks as if you've
got "old" sources hanging about in yours (i.e., Literal is no
more, it's Const these days.)
hth,
--Sigbjorn
> Felix Schroeter [mailto:[EMAIL PROTECTED]] writes:
>
> Hello!
>
> I updated new-rts via anoncvs today in the afternoon,
Hello!
I updated new-rts via anoncvs today in the afternoon, then
tried to compile, using ghc-3.02.
The compilation aborts with:
ghc-3.02 -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simpl
Alex Ferguson <[EMAIL PROTECTED]> writes:
>
>
> A build of ghc-4.01 fails for me at the following point (exactly the
> same as did ghc-4.00, see previous report). Any idea what
> causes this:
> perhaps something to do with yacc versionitis, or something like that?
>
...
> parser/hsparser.y:
A build of ghc-4.01 fails for me at the following point (exactly the
same as did ghc-4.00, see previous report). Any idea what causes this:
perhaps something to do with yacc versionitis, or something like that?
Slainte,
Alex.
_
==fptools== gnumake all --no-print-directory -r;
in /export/
Ralf Hinze <[EMAIL PROTECTED]> writes:
>
...
> ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen
> -InativeGen -Iparser
> -iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSuga
r:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:main:
reader:profiling:> parser:nat
High,
I grabbed 4.01 and tried to install it on our solaris box.
`make all' stops with
ghc -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser
-iutils:basicTypes:types:hsSyn:prelude:rename:typecheck:deSugar:coreSyn:specialise:simplCore:stranal:stgSyn:simplStg:codeGen:absCSyn:mai
On Tue, Dec 01, 1998 at 12:01:20AM -0800, Sigbjorn Finne (Intl Vendor) wrote:
> Instead of the relevant #error in includes/StgTypes.h,
> try inserting
>
> typedef unsigned long StgNat64;
> typedef signed long StgInt64;
I'll give this a try on both an Alpha/Digital Unix and Alpha/Linux
toda
Build GHC 3.02 with LibWays mp was amazingly successfully, thanks for
the good work. :) Since it's mentioned that 3.03 is the current version,
I gave it
a try too.
I got this error while compiling:
==fptools== gmake all --
Very strange - either/both of you fans of autoheader?
i.e., did you do
autoconf && ./configure --yadda
or
autoheader && autoconf && ./configure ...
Enquiring minds want to know.
--Sigbjorn
> Keith Wansbrough [mailto:[EMAIL PROTECTED]] writes:
>
> > The first compilation of ghc-4.01
> The first compilation of ghc-4.01 succeded - but I had given
> a wrong installation prefix directory.
>
> I ran configure again with the corrected prefix switch,
> followed by "gmake boot ; gmake all".
>
> Since the I get this error:
[..]
> GC.c:609: `DATA_SECTION_END_MARKER' undeclared (first
Hi,
The first compilation of ghc-4.01 succeded - but I had given
a wrong installation prefix directory.
I ran configure again with the corrected prefix switch,
followed by "gmake boot ; gmake all".
Since the I get this error:
--
[EMAIL PROTECTED] said:
>
> BTW, what is the suggsted stable version of GpH?
>
> Any GpH-heads out there who could give a definitive answer to this?
> 2.10 or 0.29 would be my guess.
I use ghc-3.02 on sparc-sun-solaris2 which I compiled up with
the vanilla binary for 3.02. As I understand it
Compiling the latest and greatest GHC-4.01 from source fails on HPs
(and probably on all other architectures with ALIGNMENT_DOUBLE >
ALIGNMENT_LONG):
...
==fptools== make all --no-print-directory -r;
in /mnt/tet
> No, I doubt we've gotten around to testing the latest batch of
> changes on Alphas (it's not on the list of platforms we hang
> out on daily.)
Actually, 4.xx hasn't received any testing on Alphas. It'll surely need
some work to get it going (but not a great deal - all the code is there, it
jus
Alexander Williams <[EMAIL PROTECTED]> writes:
>
> When building the latest 4.01 release of GHC from intermediate C files
> (bootstrapping) under dU 4.0d with Patchkit #2 in place, I get the
> following error:
>
...
> gcc -c mkNativeHdr.c -o mkNativeHdr.o
> In file included from Stg.h:29,
Shin-Cheng Mu <[EMAIL PROTECTED]> writes:
>
> Hello all,
>
> I am compiling 3.02 again for Linux, this time with kernel 2.1.129.
> The system include file /usr/include/asm/sigcontext.h defines struct
> sigcontext rather than struct sigcontext_struct. This would cause
> Signal.lc fail to compi
Hello all,
I am compiling 3.02 again for Linux, this time with kernel 2.1.129.
The system include file /usr/include/asm/sigcontext.h defines struct
sigcontext
rather than struct sigcontext_struct. This would cause Signal.lc fail to
compile.
Sigbjorn Finne has created a patch to Signal.lc for th
When building the latest 4.01 release of GHC from intermediate C files
(bootstrapping) under dU 4.0d with Patchkit #2 in place, I get the
following error:
==fptools== gmake boot --no-print-directory -r;
in /work/fptools/ghc
23 matches
Mail list logo
