I've built ghc previously and I assumed to keep it up to date I just did
darcs pull
followed by
make
but I got errors and according to the rebuilding instructions
http://hackage.haskell.org/trac/ghc/wiki/Building/Rebuilding I shouldn't
have done that.
I therefore followed the instructions but
On 6/10/08, Dominic Steinitz <[EMAIL PROTECTED]> wrote:
> I've built ghc previously and I assumed to keep it up to date I just did
>
> darcs pull
>
> followed by
>
> make
>
> but I got errors and according to the rebuilding instructions
> http://hackage.haskell.org/trac/ghc/wiki/Building/Rebui
On Tue, Jun 10, 2008 at 1:39 PM, Dominic Steinitz
<[EMAIL PROTECTED]> wrote:
> I've built ghc previously and I assumed to keep it up to date I just did
>
> darcs pull
>
> followed by
>
> make
>
> but I got errors and according to the rebuilding instructions
> http://hackage.haskell.org/trac/ghc/wik
Judah Jacobson wrote:
> On Tue, Jun 10, 2008 at 1:39 PM, Dominic Steinitz
> <[EMAIL PROTECTED]> wrote:
>> I've built ghc previously and I assumed to keep it up to date I just did
>
> From that error, I suspect you have a conflict in the editline
> package, and the compiler is barfing on the marke
On Thu, Jun 12, 2008 at 1:15 PM, Dominic Steinitz
<[EMAIL PROTECTED]> wrote:
> Judah Jacobson wrote:
>>
>> If you weren't planning on hacking editline, it's probably easiest to
>> just rm -rf the libraries/editline directory and do another "darcs-all
>> get" to replace it with a consistent version.
>>> Configuring editline-0.2...
>>> Setup: Version mismatch between ghc and ghc-pkg:
>>> /home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606
>>> /home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.20080612
>
> From the above error, I suspect that you need to run "make distclea
This is becoming a bit of an odyssey ("a series of vicissitudes"). I now
get a bug in ghc. Should I report it?
Dominic.
> /home/dom/ghc/compiler/stage1/ghc-inplace -package-name ndp-0.2
> -hide-all-packag
> es -i -idist/build -i. -idist/build/autogen -Idist/build -Iinclude -odir
> dist/bu
> ild
On Thu, Jun 12, 2008 at 1:58 PM, Dominic Steinitz
<[EMAIL PROTECTED]> wrote:
Configuring editline-0.2...
Setup: Version mismatch between ghc and ghc-pkg:
/home/dom/ghc/compiler/stage1/ghc-inplace is version 6.9.20080606
/home/dom/ghc/utils/ghc-pkg/ghc-pkg-inplace is version 6.9.
On 2008 Jun 12, at 16:58, Dominic Steinitz wrote:
Ok but doesn't that rebuild everything not just the bits that have
changed?
Enough stuff usually changes that it's necessary (and for whatever
reason dependencies don't catch enough of it).
--
brandon s. allbery [solaris,freebsd,perl,pugs
On Thu, Jun 12, 2008 at 2:04 PM, Dominic Steinitz
<[EMAIL PROTECTED]> wrote:
> This is becoming a bit of an odyssey ("a series of vicissitudes"). I now
> get a bug in ghc. Should I report it?
>
> [snip error building ndp]
This does seem worth reporting. There seem to be other outstanding
bugs whe
't compile NDP. I'll
commit a patch shortly.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
| [EMAIL PROTECTED] On Behalf Of Dominic Steinitz
| Sent: 12 June 2008 22:05
| To: Judah Jacobson
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Rebui
Brandon S. Allbery KF8NH wrote:
> On 2008 Jun 12, at 16:58, Dominic Steinitz wrote:
>> Ok but doesn't that rebuild everything not just the bits that have
>> changed?
>
> Enough stuff usually changes that it's necessary (and for whatever
> reason dependencies don't catch enough of it).
Recursive M
Simon Peyton-Jones wrote:
> Sorry about this -- it's my fault. I did validate a fix to the
> desugarer, but ndp isn't part of 'validate'. Turns out that the
> change to the desugarer provoked quite subtle and longstanding bug in
> the simplifier.
>
> To get rolling again, use -fno-ds-multi-tyvar
| Where do I put -fno-ds-multi-tyvar so that the build system knows to use
| it? I'm going to try build.mk.
|
| Ok that didn't work and I couldn't find anything about
| -fno-ds-multi-tyvar in the documentation.
Yes, in GhcLibHcOpts in build.mk is a good place. The flag isn't documented
because i
Simon Peyton-Jones wrote:
> | Where do I put -fno-ds-multi-tyvar so that the build system knows
> to use | it? I'm going to try build.mk. | | Ok that didn't work and I
> couldn't find anything about | -fno-ds-multi-tyvar in the
> documentation.
>
> Yes, in GhcLibHcOpts in build.mk is a good place.
On Mon, Jun 16, 2008 at 08:12:49AM +0100, Dominic Steinitz wrote:
>
> Thanks. I put the flag in the right place and got further but see below.
>
> > ../compiler/ghc-inplace -H32m -O2 -fasm -Rghc-timing -optc-O2 -I../includes
> > -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -fvia-C -stat
Ian Lynagh wrote:
> On Mon, Jun 16, 2008 at 08:12:49AM +0100, Dominic Steinitz wrote:
>> Thanks. I put the flag in the right place and got further but see below.
>>
>>> ../compiler/ghc-inplace -H32m -O2 -fasm -Rghc-timing -optc-O2 -I../includes
>>> -I. -Iparallel -Ism -DCOMPILING_RTS -package-name
Dear ghc developers,
I am currently rebuilding ghc-7.0.2 to upload some packaging changes.
Unfortunately, this had the effect of changing the package id of "base",
which would require rebuilding every Haskell library.
In the times of ghc-6.12, rebuilding the compiler left the hashes
Simon,
Did you say I need to check out the version from CVS and build that?
I tried building crypto with the darwinports version and it went
fine. I did not see -threaded passed to stage2 builds, though.
Thanks, Joel
--
http://wagerlabs.com/
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
> Also, the initial upload was built using ghc-6.12.1, while the upload
> now is build with ghc-7.0.2. Given that it is a two-stage compiler, I
> assume that the output should be identical, but it seems not to be the
> case.
Changin
Hi,
Am Dienstag, den 05.04.2011, 18:51 +0200 schrieb Matthias Kilian:
> On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
> > Also, the initial upload was built using ghc-6.12.1, while the upload
> > now is build with ghc-7.0.2. Given that it is a two-stage compiler, I
> > assume t
On 05/04/11 17:51, Matthias Kilian wrote:
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
Also, the initial upload was built using ghc-6.12.1, while the upload
now is build with ghc-7.0.2. Given that it is a two-stage compiler, I
assume that the output should be identical, but
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote:
> >On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
> >>Also, the initial upload was built using ghc-6.12.1, while the upload
> >>now is build with ghc-7.0.2. Given that it is a two-stage compiler, I
> >>assume that the
On 05/04/2011 23:14, Matthias Kilian wrote:
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote:
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
Also, the initial upload was built using ghc-6.12.1, while the upload
now is build with ghc-7.0.2. Given that it is a two-s
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote:
> On 05/04/11 17:51, Matthias Kilian wrote:
> >On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
> >>Also, the initial upload was built using ghc-6.12.1, while the upload
> >>now is build with ghc-7.0.2. Given that it is
On 06/04/2011 12:40, Ian Lynagh wrote:
On Tue, Apr 05, 2011 at 08:51:52PM +0100, Simon Marlow wrote:
On 05/04/11 17:51, Matthias Kilian wrote:
On Tue, Apr 05, 2011 at 09:59:23PM +0530, Joachim Breitner wrote:
Also, the initial upload was built using ghc-6.12.1, while the upload
now is build wi
On Wed, Apr 06, 2011 at 12:40:45PM +0100, Ian Lynagh wrote:
> compiler/stage2/build/Config.hs includes cBooterVersion, so if you boot
> with a different version then you get different code => different ABI.
>
> We could just remove this. In theory, stage2 won't be affected by the
> bootstrapping c
On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
> I still have to find my noticeses about wether cBooterVersion affects
> more than only the ghc lib.
Did a quick test the other day; bootstrapping ghc-7.0.3 from
ghc-6.12.3 with two different VERSION_DATE files. The only visible
cha
Hi,
Am Freitag, den 08.04.2011, 22:00 +0200 schrieb Matthias Kilian:
> On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
> > I still have to find my noticeses about wether cBooterVersion affects
> > more than only the ghc lib.
>
> Did a quick test the other day; bootstrapping ghc-7
Hi,
Am Freitag, den 08.04.2011, 22:00 +0200 schrieb Matthias Kilian:
> On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
> > I still have to find my noticeses about wether cBooterVersion affects
> > more than only the ghc lib.
>
> Did a quick test the other day; bootstrapping ghc-7
Hi again,
Am Samstag, den 09.04.2011, 10:46 +0530 schrieb Joachim Breitner:
> Am Freitag, den 08.04.2011, 22:00 +0200 schrieb Matthias Kilian:
> > On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
> > > I still have to find my noticeses about wether cBooterVersion affects
> > > more
On 09/04/11 06:16, Joachim Breitner wrote:
Hi,
Am Freitag, den 08.04.2011, 22:00 +0200 schrieb Matthias Kilian:
On Wed, Apr 06, 2011 at 08:44:33PM +0200, Matthias Kilian wrote:
I still have to find my noticeses about wether cBooterVersion affects
more than only the ghc lib.
Did a quick test
Hi,
Am Samstag, den 09.04.2011, 20:18 +0100 schrieb Simon Marlow:
> That's right, the ABI hashes are not guaranteed to be stable, and in
> practice do change unpredictably. While this doesn't affect
> correctness, I realise it's a problem for you, and it's something we'd
> like to fix. The ca
Hi Joel,
The current darwinports ghc turns off the threaded RTS by patching
a makefile during the build. With the threaded RTS you would very
likely have seen access violations in the CrashReporter log, and the
build of the crypto lib would have failed.
The crash while building the crypto libr
On Jul 26, 2006, at 2:06 PM, Gregory Wright wrote:
The crash while building the crypto library was one of the first signs
that the threaded RTS had a problem.
My question was whether the CVS version has the flag set. I looked
through mk/config.mk but could not figure it out quickly so I jus
I'm building ghc 6.4.2 from CVS on Mac PPC and get the error below.
Any clues?
==fptools== make boot - --no-print-directory -r;
in /Users/zomariya/Work/fptools/ghc/lib/compat
../../../glafp-utils/mkdependC/mkdependC -f .de
Hi Joel,
The "-threaded" flag is set in ghc/compiler/Makefile. Look around
line 398, for
SRC_HC_OPTS += -threaded
-Greg
On Jul 26, 2006, at 9:17 AM, Joel Reymont wrote:
On Jul 26, 2006, at 2:06 PM, Gregory Wright wrote:
The crash while building the crypto library was one of the first
Hi Joel,
Off the top of my head, I can't tell what is the reason for this.
What compiler are
you using to build ghc 6.4.2?
-Greg
On Jul 26, 2006, at 9:24 AM, Joel Reymont wrote:
I'm building ghc 6.4.2 from CVS on Mac PPC and get the error below.
Any clues?
==fptools== make boot - --no
This is being set in the CVS version.
On Jul 26, 2006, at 2:49 PM, Gregory Wright wrote:
Hi Joel,
The "-threaded" flag is set in ghc/compiler/Makefile. Look around
line 398, for
SRC_HC_OPTS += -threaded
--
http://wagerlabs.com/
___
Glasgo
I'm using ghc 6.4.2 from darwinports to build the CVS version.
There's positively no Cabal directory under fptools.
On Jul 26, 2006, at 2:50 PM, Gregory Wright wrote:
Hi Joel,
Off the top of my head, I can't tell what is the reason for this.
What compiler are
you using to build ghc 6.4.2
Joel Reymont wrote:
I'm building ghc 6.4.2 from CVS on Mac PPC and get the error below. Any
clues?
==fptools== make boot - --no-print-directory -r;
in /Users/zomariya/Work/fptools/ghc/lib/compat
../../../glafp-utils/mkdep
On Jul 26, 2006, at 3:20 PM, Simon Marlow wrote:
ghc/lib/compat/Distribution/Compat/FilePath.hs #include's Cabal/
Distribution/Compat/FilePath.hs, which it is supposed to find by
virtue of the -I../../../libraries arg passed to ghc.
So does Cabal/Distribution/Compat/FilePath.hs exist relati
Foot in mouth. Gotta read the manual (README).
On Jul 26, 2006, at 3:20 PM, Simon Marlow wrote:
So does Cabal/Distribution/Compat/FilePath.hs exist relative to
libraries in your tree?
--
http://wagerlabs.com/
___
Glasgow-haskell-users mailing
I checked out GHC from cvs and spent half a day building it but it
turned out to be 6.5. Is this correct? I built the crypto library
without problems.
How do I get 6.4.2 from cvs?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell
On 27 July 2006 09:48, Joel Reymont wrote:
> I checked out GHC from cvs and spent half a day building it but it
> turned out to be 6.5. Is this correct? I built the crypto library
> without problems.
>
> How do I get 6.4.2 from cvs?
You need to use -r ghc-6-4-branch when checking out, sorry abou
On Jul 27, 2006, at 9:53 AM, Simon Marlow wrote:
You need to use -r ghc-6-4-branch when checking out, sorry about that.
Ok, so I did cvs co -r ghc-6-4-branch . My build
failed after an hour.
/usr/bin/ld: warning multiple definitions of symbol _UP
/opt/local/lib/libreadline.5.dylib(termina
On 27 July 2006 12:57, Joel Reymont wrote:
> On Jul 27, 2006, at 9:53 AM, Simon Marlow wrote:
>
>> You need to use -r ghc-6-4-branch when checking out, sorry about
>> that.
>
> Ok, so I did cvs co -r ghc-6-4-branch . My build
> failed after an hour.
You didn't mention this explicitly, so just
On Jul 27, 2006, at 1:03 PM, Simon Marlow wrote:
You didn't mention this explicitly, so just to be clear: did you
update
the root of your repository to the ghc-6-4-branch too?
I started from scratch with fpconfig. I then changed into the fptools
directory and grabbed the rest. I'm gonna t
On Jul 27, 2006, at 1:03 PM, Simon Marlow wrote:
You didn't mention this explicitly, so just to be clear: did you
update
the root of your repository to the ghc-6-4-branch too?
I'm not sure what the root is but I blew everything away and did the
following:
mv fptools/ fptools.bak
cvs co -
More on allocateExec... I see this at the end of ./ghc/compiler/ghci/
ByteCodeItbls.lhs
foreign import ccall unsafe "allocateExec"
_allocateExec :: CUInt -> IO (Ptr a)
malloc_exec :: Int -> IO (Ptr a)
malloc_exec bytes = _allocateExec (fromIntegral bytes)
It does not appear that malloc_exec
It didn't take me long to discover allocateExec in ./ghc/rts/Storage.c.
I'm at a loss for clues as the build line that's trying to build
stage1 ghc and barfing does not include anything from the rts
directory. Shouldn't it?
--
http://wagerlabs.com/
_
Joel Reymont wrote:
It didn't take me long to discover allocateExec in ./ghc/rts/Storage.c.
I'm at a loss for clues as the build line that's trying to build stage1
ghc and barfing does not include anything from the rts directory.
Shouldn't it?
Ah, I see the problem. We added allocateExec(
On Jul 28, 2006, at 8:47 AM, Simon Marlow wrote:
Ah, I see the problem. We added allocateExec() after the 6.4.2,
but the version in the source tree is still 6.4.2, so GHC thinks it
is safe to assume the two versions are the same, when in fact the
6.4.2 you are bootstrapping with doesn't h
On 28 July 2006 10:54, Joel Reymont wrote:
> On Jul 28, 2006, at 8:47 AM, Simon Marlow wrote:
>
>> Ah, I see the problem. We added allocateExec() after the 6.4.2,
>> but the version in the source tree is still 6.4.2, so GHC thinks it
>> is safe to assume the two versions are the same, when in fa
On Jul 28, 2006, at 11:11 AM, Simon Marlow wrote:
cvs update in ghc/, then 'make clean' and you should be all set.
This is probably a silly question but I have never used cvs before. I
assume cvs saved the CVSROOT and the password, is that right? Also, I
only saw
P configure.ac
Should
On 28 July 2006 11:39, Joel Reymont wrote:
> On Jul 28, 2006, at 11:11 AM, Simon Marlow wrote:
>
>> cvs update in ghc/, then 'make clean' and you should be all set.
>
> This is probably a silly question but I have never used cvs before. I
> assume cvs saved the CVSROOT and the password, is that
On Jul 28, 2006, at 11:42 AM, Simon Marlow wrote:
You shouldn't have to run configure again, but make clean definitely.
I still get the same allocateExec error. I'm still not sure how
updating configure.ac in ghc and making clean was going to help :-).
--
http://wagerlabs.com/
__
On 28 July 2006 12:50, Joel Reymont wrote:
> On Jul 28, 2006, at 11:42 AM, Simon Marlow wrote:
>
>> You shouldn't have to run configure again, but make clean definitely.
>
> I still get the same allocateExec error. I'm still not sure how
> updating configure.ac in ghc and making clean was going
Hi Joel,
On Jul 28, 2006, at 7:50 AM, Joel Reymont wrote:
On Jul 28, 2006, at 11:42 AM, Simon Marlow wrote:
You shouldn't have to run configure again, but make clean definitely.
I still get the same allocateExec error. I'm still not sure how
updating configure.ac in ghc and making clean
I give up! Mac PPC doesn't like me now that I'm on Intel.
This is PPC, btw, and I _do_ have readline installed. GHC from
DarwinPorts compiles just fine.
../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.3 -H16m -O -
istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -
Joel Reymont wrote:
I give up! Mac PPC doesn't like me now that I'm on Intel.
This is PPC, btw, and I _do_ have readline installed. GHC from
DarwinPorts compiles just fine.
[snip]
/usr/bin/ld: Undefined symbols:
_rl_initialize
_rl_reset_terminal
_add_history
_readline
collect2: ld returned
Hi,
This is probably the libedit issue. On OS X, NetBSD's libedit is
installed.
Libedit provides a partial implementation of the readline API. On OS X,
Apple has symlinked /usr/lib/libreadline.dylib to libedit. This is
not a good
idea.
I submitted at patch to fix this and I think it w
Sorry to flood your mailboxes with my junk, but I had a few questions
on the configuration and Makefiles for building GHC on OS 10.4:
The odd memory bugs (wierd malloc errors) seem to remind me of errors
using pthreads...
in Joel Reymont's email, I noticed that ghc is given the -threaded option:
63 matches
Mail list logo
