On Thu, Nov 01, 2012 at 03:14:49PM +0100, Daniel Fischer wrote:
>
> > 2) Is there a bug in the build process for BuildFlavour =
> > prof?
>
> Seems so, I get the same error.
I've fixed this.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
h
On Donnerstag, 1. November 2012, 08:50:53, Richard Eisenberg wrote:
> 1) Is cabal's error correct? Do I really need to enable profiling to get
> transformers working? Or is some other incompatibility at play here? (For
> what it's worth, what I really want is the mtl library, but that depends on
>
I would like to use install the transformers library onto HEAD. I tried the
following steps:
- Fresh checkout of HEAD
- BuildFlavour = quick
- perl boot; configure; make
- make install
- cabal install transformers
Cabal errors in looking for Data.Traversable, suggesting that I need the
profilin
On Wed, Nov 02, 2011 at 06:42:19PM +, Max Bolingbroke wrote:
>
> it looks like GCC is reading the *contents of the symlink* (which is
>
> Has anyone else encountered this problem? If so, how have they fixed it?
Aha, thanks for the diagnosis!
We have to stop cygwin's ln from working, or conf
Hi GHCers,
I've noticed that the behaviour of Simon Marlow's buildbot has changed
since ~Oct 5th when libffi was upgraded in the ghc-tarballs library.
Prior to this date, the buildbot would either succeed, fail during
cloning, or fail during testing. After this date, it fails a *lot*
more. Some of
Sun Jul 13 05:13:09 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Fix some build problems when GHCI is not definde
M ./compiler/hsSyn/HsExpr.lhs -4 +1
M ./compiler/hsSyn/HsPat.lhs +9
M ./compiler/typecheck/TcSplice.lhs -3 +5
View patch online:
http://darcs.haskell.org/ghc/
Incidentally, I've just realised that if it did work then it would also
tell you that you have added all the files in all the libraries,
testsuite, etc.
indeed, and one has to be careful when filtering those out, because
mixed in between are real left-over files that need removing.. that's
one r
btw, Ian pointed out that compiler/stage1, being boring, won't even
appear in 'darcs whatsnew -l', but his suggestion to add --boring doesn't
work for me. firstly, darcs gets really memory-hungry when i add that flag,
and secondly, it gives less, rather than more output. am i doing anything
wro
On Tue, Aug 28, 2007 at 12:08:05PM +0100, Claus Reinke wrote:
> >but tried to clean most of distclean's left-overs as well, and that Ian
> >and i
> >agreed that a darcs-clean target would be helpful to automate that.
>
> btw, Ian pointed out that compiler/stage1, being boring, won't even
> appea
Claus Reinke wrote:
Claus Reinke wrote:
$ ls compiler/stage1/ghc-inplace*
compiler/stage1/ghc-inplace compiler/stage1/ghc-inplace.bat
compiler/stage1/ghc-inplace.exe
Ah, this could well be the source of the problem; you should only have
ghc-inplace.exe. Does removing the others fix i
but tried to clean most of distclean's left-overs as well, and that Ian and i
agreed that a darcs-clean target would be helpful to automate that.
btw, Ian pointed out that compiler/stage1, being boring, won't even
appear in 'darcs whatsnew -l', but his suggestion to add --boring doesn't
work f
Claus Reinke wrote:
$ ls compiler/stage1/ghc-inplace*
compiler/stage1/ghc-inplace compiler/stage1/ghc-inplace.bat
compiler/stage1/ghc-inplace.exe
Ah, this could well be the source of the problem; you should only have
ghc-inplace.exe. Does removing the others fix it?
i changed the Ma
Claus Reinke wrote:
$ ls compiler/stage1/ghc-inplace*
compiler/stage1/ghc-inplace compiler/stage1/ghc-inplace.bat
compiler/stage1/ghc-inplace.exe
Ah, this could well be the source of the problem; you should only have
ghc-inplace.exe. Does removing the others fix it?
i changed the Ma
On Sunday 26 August 2007 14:38, I wrote:
> [...]
>c) "make install" gets an additional argument "prefix=/var/foo/usr"
> (where "/var/foo" is some temporary place and "/usr" is what was stated in
> the configure stage for "--prefix"), so everything gets installed
> below "/var/foo/usr". After so
On Sun, Aug 26, 2007 at 02:54:20PM +0100, Claus Reinke wrote:
> >> $ ls compiler/stage1/ghc-inplace*
> >> compiler/stage1/ghc-inplace compiler/stage1/ghc-inplace.bat
> >> compiler/stage1/ghc-inplace.exe
> >
> >Ah, this could well be the source of the problem; you should only have
> >ghc-inpl
On Sunday 26 August 2007 15:56, I wrote:
> GHCBIN and TOPDIROPT in the shell script wrappers for ghc and ghci contain
> the install-time prefix (not the correct build-time one) [...]
Furthermore, the package.conf is incorrect, too, as I just found out. :-(
Cheers,
S.
On Sunday 26 August 2007 15:29, Ian Lynagh wrote:
> Exactly which paths are getting baked in where?
>
> If it's the libraries causing problems then I think we need to set a
> CopyDest in installPackage.hs.
GHCBIN and TOPDIROPT in the shell script wrappers for ghc and ghci contain the
install-time
$ ls compiler/stage1/ghc-inplace*
compiler/stage1/ghc-inplace compiler/stage1/ghc-inplace.bat
compiler/stage1/ghc-inplace.exe
Ah, this could well be the source of the problem; you should only have
ghc-inplace.exe. Does removing the others fix it?
i changed the Makefile to pass the .e
On Sun, Aug 26, 2007 at 02:38:27PM +0200, Sven Panne wrote:
> I'm currently trying to resurrect ghc.spec.in after all those build system
> changes in the last few months. One thing I'm currently fighting with is the
> totally obscure non-standard logic regarding the handling of build/install
> p
I'm currently trying to resurrect ghc.spec.in after all those build system
changes in the last few months. One thing I'm currently fighting with is the
totally obscure non-standard logic regarding the handling of build/install
prefixes. Just to recap what is needed for sane (non-relocatable) RPM
On Sun, Aug 26, 2007 at 01:05:53PM +0100, Claus Reinke wrote:
>
> note that there are no fewer than three versions of
> ghc-inplace:
>
>$ ls compiler/stage1/ghc-inplace*
>compiler/stage1/ghc-inplace compiler/stage1/ghc-inplace.bat
>compiler/stage1/ghc-inplace.exe
Ah, this could w
Setup.exe: ghc version >=6.2 is required but the version of
..\..\compiler\stage1\ghc-inplace could not be determined.
What do
compiler/stage1/ghc-inplace -v --version
compiler/stage1/ghc-inplace -v --numeric-version
say?
$ compiler/stage1/ghc-inplace -v --version
Using c:/fptools/
On Sat, Aug 25, 2007 at 03:43:51PM +0100, Claus Reinke wrote:
> trying to build head on windows, with ghc-6.6.1, i get Setup warnings,
> followed by a Setup error. if i read the make log correctly, that Setup
> was build with bootstrapping.Cabal, so there ought to be no warnings,
> right?
The warn
trying to build head on windows, with ghc-6.6.1, i get Setup warnings,
followed by a Setup error. if i read the make log correctly, that Setup
was build with bootstrapping.Cabal, so there ought to be no warnings,
right? and there is no dist/ in base/ at that point.
also confusing: buildbot report
On Mon, May 28, 2007 at 10:13:57PM +1000, Gabriele Keller wrote:
> I had a serious problem building ghc head under Intel MacOS today. The
> first problem was that the FIND makefile var wasn't initialized
> properly.
Can you please send me config.log?
Also, what do these commands say?:
* which
Hello,
Please refer to
http://www.haskell.org/pipermail/glasgow-haskell-users/2007-April/012290.html
and the mail thread leading up to this response. It seems to be the same
problem.
Best regards
Thorkil
On Monday 28 May 2007 14:13, Gabriele Keller wrote:
> I had a serious problem building ghc
I had a serious problem building ghc head under Intel MacOS today. The
first problem was that the FIND makefile var wasn't initialized
properly. A log of the second problem is attached
Cheers,
Gabriele
-=-
rm -f -f stamp/configure.library.*.base base/unbuildable
( cd base && setup/Setup conf
27 matches
Mail list logo
