George Colpitts writes:
snip
> ,("target has GNU nonexec stack","False")
> ,("target has .ident directive","True")
> ,("target has subsections via symbols","True")
> ,("Unregisterised","NO")
> ,("LLVM llc command","llc")
> ,("LLVM opt command","opt")
> ,("Project version","8.0.0.20160111")
"/usr/local/bin/ghc" -M -static -H32m -O -Wall -package-db
libraries/bootstrapping.conf -this-unit-id terminfo-0.4.0.2
-hide-all-packages -i -ilibraries/terminfo/.
-ilibraries/terminfo/dist-boot/build
-ilibraries/terminfo/dist-boot/build/autogen
-Ilibraries/terminfo/dist-boot/build
-Ilibraries/
It looks like you will have to install old versions of mtl/exceptions
which work on transformers-0.3.0.0, although undoubtedly the real
problem is that GHC should update what version of transformers it
is distributing.
Edawrd
Excerpts from i hamsa's message of 2014-07-20 19:25:36 +0100:
> I think
I think I found the problem.
package ghc-7.8.3 requires transformers-0.3.0.0
package mtl-2.2.1 requires transformers-0.4.1.0
package exceptions-0.6.1 requires transformers-0.4.1.0
I wonder how is this ever supposed to work :(
On Sun, Jul 20, 2014 at 9:01 PM, Edward Z. Yang wrote:
> The last tim
The last time I saw this error, it was because the package database
was messed up (there was an instance of MonadIO in scope, but it
was for the wrong package.) However, I don't know what the source
of the problem is here.
Edward
Excerpts from i hamsa's message of 2014-07-20 08:26:52 +0100:
> I
I was trying to upgrade to ghc-7.8 the other day, and got this
compilation failure when building ghc-mtl-1.2.1.0 (see the end of the
message).
I'm using the haskell overlay on Gentoo Linux straight out of the box,
no local cabal installations of anything.
Now I was told that other people can comp
I'm trying to cross-compile GHC 7.6.3; 'make' fails with the mentioned
error. How can I debug this issue?
I used Guix [1] to build a cross-compiler and related packages:
# ./pre-inst-env guix build -K gcc-cross-mips64el-linux-gnu
After that I downloaded GHC 7.6.3:
# wget http://www.haskell.org
> Is /usr/bin/gcc a MIPS cross-compiler? If not, how do you expect it
> to work?
Right, I wasn't using a cross-compiler. That's the problem.
I haven't succeeded in cross-building yet. I'm using a distro with a
non-common directory structure and I still have to figure out how to
specify both GC
I'd like to cross-build GHC 7.6.2. I got stuck when I was trying to
build a Stage 1 compiler [1]. Here's a bug report: [2,3].
I'm not sure that it's a bug; maybe I misunderstood the process.
Could anyone advise?
I have no experience with C. Though, I'll try to help out.
[1] http://hackage.has
Why cross compile when we already have a native GHC on OpenBSD/x86_64 ..
use that to build the source directly.
khaelin:
> Hi,
>
> I'm trying to cross-compile GHC as follows:
>
> Host: Linux, x86_64, GHC 6.12.1
> Target: OpenBSD 4.6 stable, i386
>
> I follow the guide at:
> http://hackage.h
On Fri, Jan 29, 2010 at 09:42:27PM +0100, Nicolas Martyanoff wrote:
> > This probably means some type identifier used at that point hasn't
> > been declared, or macro defined or whatever. You'd have to see
> > what it is, and maybe it will be more obvious what went wrong.
> It seems that SIZEOF_VO
Quoth Nicolas Martyanoff ,
> It seems that SIZEOF_VOID_P isn't defined anywhere.
I guess it's immaterial if you aren't going to pursue the port
strategy any farther, but from a cursory look, this would happen
at the point where the configuration log says "checking size of void *".
That's failing
On 10-01-29 11:54, Donn Cave wrote:
> Quoth Nicolas Martyanoff ,
> ...
> > The latest fails, with the following trace:
> > http://pastebin.ca/1770926
>
> Can you look at the include files, at the locations where all these
> errors crop up? like,
> includes/stg/Types.h:118: error: syntax err
Quoth Nicolas Martyanoff ,
...
> The latest fails, with the following trace:
> http://pastebin.ca/1770926
Can you look at the include files, at the locations where all these
errors crop up? like,
includes/stg/Types.h:118: error: syntax error before '*' token
This probably means some type i
On Fri, Jan 29, 2010 at 06:10:52PM +0100, Nicolas Martyanoff wrote:
> I'm trying to cross-compile GHC as follows:
>
> Host: Linux, x86_64, GHC 6.12.1
> Target: OpenBSD 4.6 stable, i386
IMHO, you shouldn't go that way, because it adds much more complexity
than you already have with OpenBSD as host
Hi,
I'm trying to cross-compile GHC as follows:
Host: Linux, x86_64, GHC 6.12.1
Target: OpenBSD 4.6 stable, i386
I follow the guide at:
http://hackage.haskell.org/trac/ghc/wiki/Building/Porting
I downloaded the last stable source tarball (ghc-6.12.1-src.tar.bz2), then ran
the following comm
On 5/3/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
I think I have fixed it...
You did, thanks very much!
GHC now builds and install without any errors, jippy!
Thanks,
Bas van Dijk
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@h
: glasgow-haskell-users@haskell.org
| Subject: Re: Error compiling GHC/Num.lhs
|
| On 5/2/07, Bertram Felgenhauer <[EMAIL PROTECTED]> wrote:
| > ...
| > I have two patches that should fix this:
| > ...
|
| Thanks, I applied base-install-includes.patch.
| (Cabal-fix-installInclude
On 5/2/07, Bertram Felgenhauer <[EMAIL PROTECTED]> wrote:
...
I have two patches that should fix this:
...
Thanks, I applied base-install-includes.patch.
(Cabal-fix-installIncludeFiles.patch was already applied according to
darcs.)
However, in order to apply the patches I did a new checkout of
[Note: Sorry if this is a duplicate. I originally sent the patches
inline in the mail, but the resulting mail grew rather big and is
"awaiting moderators approval" now. (moderators: no need to approve it)]
Bas van Dijk wrote:
> On 5/2/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
> >I believe this o
On 5/2/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
I believe this one is now fixed, sorry about that.
No problem. I'm now able to successfully make GHC. Thanks about that!
However 'make install' fails:
$ make install
...
ifBuildable/ifBuildable base setup/Setup install
copy directory 'dist/d
Bas van Dijk wrote:
On 5/2/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
Thanks, I think I've fixed this one now.
You did indeed, thanks!
Now I get another error when compiling main/GHC.hs:
../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64
-opta-march=athlon64 -istage2/uti
On 5/2/07, Simon Marlow <[EMAIL PROTECTED]> wrote:
Thanks, I think I've fixed this one now.
You did indeed, thanks!
Now I get another error when compiling main/GHC.hs:
../compiler/stage1/ghc-inplace -H64m -Onot -fasm -optc-march=athlon64
-opta-march=athlon64 -istage2/utils -istage2/basicTyp
Bas van Dijk wrote:
However the build now crashes when running Haddock on Cabal:
...
ifBuildable/ifBuildable Cabal setup/Setup haddock
Preprocessing library Cabal-1.1.7...
Running Haddock for Cabal-1.1.7...
Warning: cannot use package base-2.1:
ghc-pkg failed
dist/build/tmp/Distribution/PrePro
On 4/29/07, Ian Lynagh <[EMAIL PROTECTED]> wrote:
Hi Bas,
On Sun, Apr 29, 2007 at 11:54:35AM +, Bas van Dijk wrote:
>
> I'm trying to build GHC from darcs. Unfortunately compilation fails
> with the following error:
>
> ...
> cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8
Hi Bas,
On Sun, Apr 29, 2007 at 11:54:35AM +, Bas van Dijk wrote:
>
> I'm trying to build GHC from darcs. Unfortunately compilation fails
> with the following error:
>
> ...
> cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1)
> in GHC/Num.lhs at line 27 col 1
> make[1]:
Hello,
I'm trying to build GHC from darcs. Unfortunately compilation fails
with the following error:
...
cpphs: #error Please define LEFTMOST_BIT to be 2^(SIZEOF_HSWORD*8-1)
in GHC/Num.lhs at line 27 col 1
make[1]: *** [doc.library.base] Error 1
make[1]: Leaving directory `/home/bas/development
I got my problem solved just by deleting ghc* from /usr/local/bin.
Weird, I know. I didn't have that problem again since that time but I left
this post "open" because I wanted to know if someone else had had the same
problem and the way he/she got rid of it.
Cheers.
Cristian
On 3/2/07, Ian Lynagh
On Mon, Feb 26, 2007 at 02:48:38PM +0100, Cristian Perfumo wrote:
>
> So, what I did, to be sure that the error had nothing to do with my
> modification, was to download GHC again and try to build the original
> version. But I still get the same error (that I paste below this message).
So you're
Hi all,
I'm having a problem when I try to compile GHC. I did it several times
before without any problem but I don't know exactly from which moment it
started giving me errors. Anyway, I have some clues:
1) I was modifying some STM stuff and I was receiving errors with (I think)
out of date info
On Mon, 16 Oct 2006, Simon Marlow wrote:
There's one restriction that I know of: you should be careful not to cast a
function value to a non-function type (except a polymorphic type), because
the two have incompatible representations when it comes to seq and case.
And of course, you should nev
FWIW, Lennart Augustsson's Cayenne compiler can compile to GHC
nowadays. It uses exactly this method of sprinkling coerce all over
the place to make GHC's typechecker happy.
http://www.augustsson.net/Darcs/Cayenne/
Cheers,
Josef
On 10/16/06, Simon Marlow <[EMAIL PROTECTED]> wrote:
Neil Mitche
Neil Mitchell wrote:
I would like to write a translator which takes a Haskell-like language
to GHC compilable Haskell. This Haskell-like language is not
explicitly typed, and cannot have types inferred for it (rank 2 types
may exist etc), however it is known that the program will not crash
with
| How does GHC react to a really large number of unsafeCoerce's? Is this
| likely to destroy performance? Has anything like this been done
| before? I know that LML was able to "turn off" the type checker, but I
| guess GHC doesn't have such an option, because of its typed Core
| language.
I've ne
Hi,
I would like to write a translator which takes a Haskell-like language
to GHC compilable Haskell. This Haskell-like language is not
explicitly typed, and cannot have types inferred for it (rank 2 types
may exist etc), however it is known that the program will not crash
with a type error. All
On 11/18/05, Esa Ilari Vuokko <[EMAIL PROTECTED]> wrote:
> On 11/18/05, Simon Marlow <[EMAIL PROTECTED]> wrote:
> > I think I have just fixed this (modification to the mangler in
> > ghc/driver/mangler), please try again.
>
> It compiles again! Thanks!
>
> ..but it still crashes on installed locat
On 11/18/05, Simon Marlow <[EMAIL PROTECTED]> wrote:
> I think I have just fixed this (modification to the mangler in
> ghc/driver/mangler), please try again.
It compiles again! Thanks!
..but it still crashes on installed location, probably still while
reading the package.conf But it seems you
On 17 November 2005 21:37, Esa Ilari Vuokko wrote:
> On 11/17/05, Esa Ilari Vuokko <[EMAIL PROTECTED]> wrote:
>> I will start a new clean build, hope it goes away and I need to look
>> into buying non-broken hardware... ;)
>
> The build failed and I sent mail about it on cvs-ghc list this time,
>
On 11/17/05, Esa Ilari Vuokko <[EMAIL PROTECTED]> wrote:
> I will start a new clean build, hope it goes away and I need to look into
> buying
> non-broken hardware... ;)
The build failed and I sent mail about it on cvs-ghc list this time, even if
something seemed to rip away my message and just l
On 11/17/05, Simon Marlow <[EMAIL PROTECTED]> wrote:
> On 17 November 2005 06:15, Esa Ilari Vuokko wrote:
>
> I haven't seen this, but I'm just updating my Windows build to try to
> reproduce. Does it happen with the stage1 or stage2 compiler? What
> version of GHC are you bootstrapping with?
S
On 17 November 2005 06:15, Esa Ilari Vuokko wrote:
> I tried to compile ghc from cvs head in windows, hosting and
> targetting mingw. When I got ghc to compile, it crashes while
> parsing (I putStrLn-debugged) package.conf, but only from installed
> position.
>
> Basically, somewhere inside Par
Hi!
I tried to compile ghc from cvs head in windows, hosting and
targetting mingw. When I got ghc to compile, it crashes while
parsing (I putStrLn-debugged) package.conf, but only from installed
position.
Basically, somewhere inside ParsePkgConf.loadPackageConfig GHC crashes
with access violati
On 18 February 2005 09:42, Simon Marlow wrote:
> On 18 February 2005 01:02, Donald Bruce Stewart wrote:
>
>> This is a known problem with gcc-2.95.
>> We came across it back in September.
>>
>> It was noticed in the nightly builds:
>>
>> http://www.haskell.org/pipermail/cvs-all/2004-September/0
Simon Marlow wrote:
On 18 February 2005 10:17, Seth Kurtzberg wrote:
Simon, you'll never give up. The crashes are absolutely repeatable.
The fact that I haven't identified a deterministic way to reproduce
them does not in any way imply that a deterministic way to reproduce
them
On 18 February 2005 10:17, Seth Kurtzberg wrote:
> Simon, you'll never give up. The crashes are absolutely repeatable.
> The fact that I haven't identified a deterministic way to reproduce
> them does not in any way imply that a deterministic way to reproduce
> them does not exist. And, as I've
Seth Kurtzberg <[EMAIL PROTECTED]> writes:
> Simon, you'll never give up. The crashes are absolutely repeatable.
> The fact that I haven't identified a deterministic way to reproduce them
> does not in any way imply that a deterministic way to reproduce them
> does not exist. And, as I've sa
Simon Marlow wrote:
On 18 February 2005 04:26, Seth Kurtzberg wrote:
At least this proves that it isn't a hardware problem. :)
Seth, you're a bit confused. This error from gcc is a deterministic,
repeatable, crash due to a known bug in gcc 2.95.
You were complainin
On 18 February 2005 09:38, Remi Turk wrote:
>>> On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should
look into whether there's a workaround, otherwise we're hosed on
FreeBSD 4.x.
>
> (though I now assume it p
On 18 February 2005 01:02, Donald Bruce Stewart wrote:
> This is a known problem with gcc-2.95.
> We came across it back in September.
>
> It was noticed in the nightly builds:
>
> http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html
>
> And then we chased it up:
>
> http:/
On Fri, Feb 18, 2005 at 12:02:06PM +1100, Donald Bruce Stewart wrote:
> rturk:
> > In case you've got nothing else left to do.. ;)
> >
> > The ghc command which perfectly repeatable kills gcc:
>
> This is a known problem with gcc-2.95.
> We came across it back in September.
>
> It was noticed i
On 18 February 2005 04:26, Seth Kurtzberg wrote:
> At least this proves that it isn't a hardware problem. :)
Seth, you're a bit confused. This error from gcc is a deterministic,
repeatable, crash due to a known bug in gcc 2.95.
You were complaining about random unrepeatable crashes, which ar
Remi Turk wrote:
[...] When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc
--with-gcc=/usr/local/bin/gcc3
[...]
Slightly off-topic: You don't need --enable-hopengl anymore when compiling
GHC 6.4 or the
CVS HEAD, the OpenGL/GLUT/O
Remi Turk wrote:
On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die
with "internal compiler error", I tried to compile it with gcc
3.4.3 (or rather
rturk:
> [Resent, with a few #ifdef FOO's removed from the body (still in
> the attachement, and using gzip instead of bzip2 to prevent
> "awaiting moderation ;)]
>
> On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
> > On 17 February 2005 11:12, Remi Turk wrote:
> >
> > > when compi
[Resent, with a few #ifdef FOO's removed from the body (still in
the attachement, and using gzip instead of bzip2 to prevent
"awaiting moderation ;)]
On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
> On 17 February 2005 11:12, Remi Turk wrote:
>
> > when compiling the new ghc pre-re
Simon Marlow wrote:
On 17 February 2005 12:43, Seth Kurtzberg wrote:
Simon Marlow wrote:
On 17 February 2005 12:05, Seth Kurtzberg wrote:
I'm not positive about 2.95, but I know that on 3.x it crashes in
different places, and even compiling different source files. With
each 3.x rel
On Thu, Feb 17, 2005 at 11:29:41AM -, Simon Marlow wrote:
> On 17 February 2005 11:12, Remi Turk wrote:
>
> > when compiling the new ghc pre-releases made my gcc 2.95.3 die
> > with "internal compiler error", I tried to compile it with gcc
> > 3.4.3 (or rather, I thought it compiled with 3.4.1
On 17 February 2005 12:54, Seth Kurtzberg wrote:
> Here are the bug reports:
>
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_statu
s=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=WAITING&bug_sta
tus=SUSPENDED&field0-0-0=product&type0-0-0=substring&value0-0-0=internal
On 17 February 2005 12:43, Seth Kurtzberg wrote:
> Simon Marlow wrote:
>
>> On 17 February 2005 12:05, Seth Kurtzberg wrote:
>>
>>
>>
>>> I'm not positive about 2.95, but I know that on 3.x it crashes in
>>> different places, and even compiling different source files. With
>>> each 3.x releas
Seth Kurtzberg wrote:
Here are the bug reports:
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=WAITING&bug_status=SUSPENDED&field0-0-0=product&type0-0-0=substring&value0-0-0=internal&field0-0-1=component&type0-0-1=sub
Simon Marlow wrote:
On 17 February 2005 12:05, Seth Kurtzberg wrote:
I'm not positive about 2.95, but I know that on 3.x it crashes in
different places, and even compiling different source files. With
each 3.x release, they fix some of them, but others pop up to take
their place. Clearly the g
Malcolm Wallace wrote:
Seth Kurtzberg <[EMAIL PROTECTED]> writes:
There has to be one, because the problem occurs when you compile gcc
with gcc. I'll look for a specific bug report. It happens much more
frequently with 3.x than with 2.95, in my testing, but that was not a
tes
Malcolm Wallace wrote:
Seth Kurtzberg <[EMAIL PROTECTED]> writes:
There has to be one, because the problem occurs when you compile gcc
with gcc. I'll look for a specific bug report. It happens much more
frequently with 3.x than with 2.95, in my testing, but that was not a
test of compiling
Malcolm Wallace wrote:
Seth Kurtzberg <[EMAIL PROTECTED]> writes:
There has to be one, because the problem occurs when you compile gcc
with gcc. I'll look for a specific bug report. It happens much more
frequently with 3.x than with 2.95, in my testing, but that was not a
test of compiling
Seth Kurtzberg <[EMAIL PROTECTED]> writes:
> There has to be one, because the problem occurs when you compile gcc
> with gcc. I'll look for a specific bug report. It happens much more
> frequently with 3.x than with 2.95, in my testing, but that was not a
> test of compiling Haskell, so I hav
On Thu, Feb 17, 2005 at 05:05:18AM -0700, Seth Kurtzberg wrote:
> Remi Turk wrote:
> >I'm afraid finding a workaround for compilers dying on
> >compiler-generated code isn't going to be much fun...
> >
> >Anyway, I just replaced a
> > ifneq "$(INSTALL_LIBS)" ""
> >by
> > ifneq "$(strip
On 17 February 2005 12:05, Seth Kurtzberg wrote:
> I'm not positive about 2.95, but I know that on 3.x it crashes in
> different places, and even compiling different source files. With
> each 3.x release, they fix some of them, but others pop up to take
> their place. Clearly the gcc people don'
Remi Turk wrote:
On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote:
Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die
with "internal compiler error",
Simon Marlow wrote:
On 17 February 2005 11:49, Seth Kurtzberg wrote:
Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die
with "internal compiler error", I tried to
On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote:
> Simon Marlow wrote:
>
> >On 17 February 2005 11:12, Remi Turk wrote:
> >
> >
> >
> >>when compiling the new ghc pre-releases made my gcc 2.95.3 die
> >>with "internal compiler error", I tried to compile it with gcc
> >>3.4.3 (or ra
On 17 February 2005 11:49, Seth Kurtzberg wrote:
> Simon Marlow wrote:
>
>> On 17 February 2005 11:12, Remi Turk wrote:
>>
>>
>>
>>> when compiling the new ghc pre-releases made my gcc 2.95.3 die
>>> with "internal compiler error", I tried to compile it with gcc
>>> 3.4.3 (or rather, I thought
Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die
with "internal compiler error", I tried to compile it with gcc
3.4.3 (or rather, I thought it compiled with 3.4.1, and when that
died, compiled+installed gcc 3.4.3, trie
On 17 February 2005 11:12, Remi Turk wrote:
> when compiling the new ghc pre-releases made my gcc 2.95.3 die
> with "internal compiler error", I tried to compile it with gcc
> 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that
> died, compiled+installed gcc 3.4.3, tried again, say i
Hi,
when compiling the new ghc pre-releases made my gcc 2.95.3 die
with "internal compiler error", I tried to compile it with gcc
3.4.3 (or rather, I thought it compiled with 3.4.1, and when that
died, compiled+installed gcc 3.4.3, tried again, say it die again
and only then noticed it was actuall
On 12 February 2005 18:30, Alain Cremieux wrote:
> When compiling ghc-6.4.20050211 with itself, I get :
>
> /usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O
> -i../../lib/compat -Rghc-timing -Wall Main.hs
> ../../lib/compat/Compat/RawSystem.hs:19: ../../inclu
When compiling ghc-6.4.20050211 with itself, I get :
/usr/local/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O
-i../../lib/compat -Rghc-timing -Wall Main.hs
../../lib/compat/Compat/RawSystem.hs:19: ../../includes/ghcconfig.h: No
such file or directory
I verified the version of ghc
Christian Maeder wrote:
The actual error not messed up by warnings is:
../../ghc/compiler/ghc-inplace -optc-O -optc-w -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-Wbad-function-cast -optc-I../include
Christian Maeder wrote:
[EMAIL PROTECTED] -> rpm -q gcc
gcc-3.3.3-41
"make" (in ghc-6.2.1) fails (in ghc/GC.c) with:
GC.c: In function `threadLazyBlackHole':
GC.c:4049: warning: use of cast expressions as lvalues is deprecated
make[2]: *** [GC.o] Fehler 1
The actual error not messed up by warnings
maril_manson:
> I try to compile ghc 6.0.1 on RH 9. In my compile-it-my-self-fanatism I
> need to do a two-stage-bootstrap. As explained in the porting and
> bootstrapping documentation I used the cross-port script distrbuted with
> the source. But in the first stage ghc issues an error message
Hi list
I try to compile ghc 6.0.1 on RH 9. In my compile-it-my-self-fanatism I
need to do a two-stage-bootstrap. As explained in the porting and
bootstrapping documentation I used the cross-port script distrbuted with
the source. But in the first stage ghc issues an error message as follows:
--
Hi.
I had the same problem and I solved it by turning of object-file
splitting by setting
SplitObjs = NO
in mk/build.mk.
Good luck, Calle
On Tue, 2003-07-01 at 15:00, Andre Rauber Du Bois wrote:
> Hello!
>
> I am trying to compile GHC 6 on an Atlhon 1700+ running Red Hat 9 and
> using GHC 6
In local.glasgow-haskell-users, you wrote:
> I am trying to compile GHC 6 on an Atlhon 1700+ running Red Hat 9 and
> using GHC 6, installed from the .rpm that is available in the GHC web
> page... After compiling for a long time I get this message:
>
> xargs: /usr/bin/ar: terminated by signal 9
Hello!
I am trying to compile GHC 6 on an Atlhon 1700+ running Red Hat 9 and
using GHC 6, installed from the .rpm that is available in the GHC web
page... After compiling for a long time I get this message:
xargs: /usr/bin/ar: terminated by signal 9
make[2]: *** [libHSbase.a] Error 125
make[2]:
On Mon, Mar 17, 2003 at 11:18:21AM +0100, Volker Stolz wrote:
> Am 17. Mar 2003 um 02:04 CET schrieb Kirsten Chevalier:
> > On Sun, Mar 16, 2003 at 04:09:31PM +0100, Volker Stolz wrote:
> > > In local.glasgow-haskell-users, you wrote:
> > > > Sendfile.hsc:94:
> > > > Couldn't match `IO ()' agai
Am 17. Mar 2003 um 02:04 CET schrieb Kirsten Chevalier:
> On Sun, Mar 16, 2003 at 04:09:31PM +0100, Volker Stolz wrote:
> > In local.glasgow-haskell-users, you wrote:
> > > Sendfile.hsc:94:
> > > Couldn't match `IO ()' against `Fd -> Fd -> Int -> Int -> IO ()'
> >
> > Should be fixed in CVS no
* Kirsten Chevalier <[EMAIL PROTECTED]> [2003-03-17T01:09-0800]:
> configure says:
>
> checking for sendfile in sys/sendfile.h... no
> checking for sendfile in sys/socket.h... no
>
> I tried building again just now, just to be sure, and still got the same error
> message ("Sendfile.hsc:19: Variab
On Mon, Mar 17, 2003 at 11:40:58AM +0100, Wolfgang Thaller wrote:
> As far as I can tell right now, "sendfile" is not supported on Mac OS X.
> There's no manual page, and it doesn't seem to be in any sytem library.
> There is a prototype in sys/socket.h, but it's wrapped in an #ifdef
> that's nev
As far as I can tell right now, "sendfile" is not supported on Mac OS X.
There's no manual page, and it doesn't seem to be in any sytem library.
There is a prototype in sys/socket.h, but it's wrapped in an #ifdef
that's never #defined.
When I last build the HEAD here, I didn't have any problems -
On Sun, Mar 16, 2003 at 04:09:31PM +0100, Volker Stolz wrote:
> In local.glasgow-haskell-users, you wrote:
> > Sendfile.hsc:94:
> > Couldn't match `IO ()' against `Fd -> Fd -> Int -> Int -> IO ()'
>
> Should be fixed in CVS now, thanks!
Now I'm getting the following error instead:
../../ghc/
In local.glasgow-haskell-users, you wrote:
> Sendfile.hsc:94:
> Couldn't match `IO ()' against `Fd -> Fd -> Int -> Int -> IO ()'
Should be fixed in CVS now, thanks!
--
http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME
rage against the finite state machine
I'm getting the following error message trying to compile the latest version
of GHC on Mac OS 10.2.1, using GHC 5.04.2 installed from binaries:
../../ghc/compiler/ghc-inplace -H16m -O -Iinclude -package-name unix -O -Rghc-timing
-p\
ackage base -split-objs-c System/Sendfile.hs -o System/Send
> I apologize if this is not the correct moment-place to deal with this
> old version.
>
> I'm trying to compile the GHC-3.02 version using ghc-2.10 binaries,
> happy-1.6 binaries on a i386-unknown-linux.
> In the future I would like to hack with it.
[ I presume you have a good reason for need
I apologize if this is not the correct moment-place to deal with this
old version.
I'm trying to compile the GHC-3.02 version using ghc-2.10 binaries,
happy-1.6 binaries on a i386-unknown-linux.
In the future I would like to hack with it.
I had to modify the file ghc/run_time/main/Signals.lc be
I am using Cygwin on an NT4SP5. I have a recent (i.e.,
up to date) installation of Cygwin (1.1.8-2).
I installed ghc 4.08.2, and it seems to work. At least
the simple "hello" works, and happy-1.9 seemed to compile
and install with no problems.
When I tried to compile ghc-5.00, my "make" run en
I'm trying to build the latest version of GHC, from CVS, and everything goes
fine until it gets to the file Parser.hs. At this point, it gets stuck on this
file for a couple of hours, then quits with either an "out of memory" message
or the message "Haskell compiler received signal 9". I've tried
> I get the following compile error:
>
> (My configuration is Linux kernel 2.4.0-test1, gcc 2.91.66 and
> ghc 4.06 installed)
I suggest upgrading your gcc; we use 2.95.2 here without any problems.
Alternatively, a workaround for the short term is this patch to
fptools/ghc/driver/ghc-asm.lprl:
I get the following compile error:
(My configuration is Linux kernel 2.4.0-test1, gcc 2.91.66 and
ghc 4.06 installed)
PWD = /home/gemi/fptools/ghc/lib/std
rm -f PrelBase.o ; if [ ! -d PrelBase ]; then mkdir PrelBase; else
Hi!
Finally I have a self-compiled solaris-ghc that does not buserror when being
used... but now there is another problem:
When compiling ghc/lib/std/PrelNumExtra.lhs, ghc (well, it's 'as') says:
../../../ghc/driver/ghc -optc-g -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing
Steve Frampton <[EMAIL PROTECTED]> wrote,
> Anybody know where I can grab a copy of "happy" for Linux glibc,
> preferably source or binary RPM format?
RPM is at
ftp://greyarea.is.tsukuba.ac.jp/pub/jibunmaki/
Manuel
Hello folks:
Thanks to everyone who replied to my message. I have decided to go with
'hugs' based on your recommendations, and since that is the Haskell
interpreter used at school.
Cheers...
--< LINUX: The choice of a GNU generation. >--
Steve Frampton <[EMAIL PROTECTE
1 - 100 of 101 matches
Mail list logo
