I have Mountain Lion (10.8.2, to be exact) with XCode 4.6 installed, and I can
build GHC. I don't use XCode when building, but I believe the command-line dev
tools (like gcc) are shipped with XCode, so that might be something to look at.
Sorry I don't have any more suggestions!
Richard
On Mar 1
On 03/14/2013 09:36 PM, Austin Seipp wrote:
> My stage2 compiler got built and also fails on any compilation, no
> matter how trivial. After linking stage2, my build fails with:
>
> $ make
> ===--- building phase 0
> make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
> make[1]: Nothing t
My stage2 compiler got built and also fails on any compilation, no matter
how trivial. After linking stage2, my build fails with:
$ make
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
m
TICKY_TICKY is the right #def to check, and it should work the straightforward
way. Why doesn't
#ifdef TICKY_TICKY
#define MYBUMP(ctr,n) ctr = ctr + n
#else
#define MYBUMP(ctr,n) /* nothing */
#endif
work?
As a trick, you can check and make sure TICKY_TICKY is actually defined by
inserting an #
I'm trying to enable some ticky counters for profiling the RTS code (eg in
Storage.c:allocate). Much of the code was already in place, but disabled
via CPP.
I can enable the counters, but I'm having trouble making them only tick in
the debug RTS.
Can someone advise regarding the presence/accuracy
On Thu, 2013-03-14 at 21:29 +0200, Roman Cheplyaka wrote:
> * Duncan Coutts [2013-03-14 17:12:14+]
> > The InstalledPackageInfo and its parser is what ghc and ghc-pkg
> > primarily use (though there's the opportunity to share code for handling
> > package indexes) and that type and that parser
* Duncan Coutts [2013-03-14 17:12:14+]
> The InstalledPackageInfo and its parser is what ghc and ghc-pkg
> primarily use (though there's the opportunity to share code for handling
> package indexes) and that type and that parser are also going to end up
> using text and parsec etc.
Correct me
My stage 2 compiler was crashing the first time it was invoked.
I just finished building GHC HEAD using LLVM compiled from HEAD, and that
worked, so perhaps this was just a 3.2 bug. I have yet to run the
testsuite though.
Geoff
On 03/14/2013 07:16 PM, Jan Stolarek wrote:
> Goeff, Austin,
>
> do
Goeff, Austin,
do the build errors always happen with the same module or do they occur
randomly? If the former,
which modules do you have problems with?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-
Austin is correct - I have built LLVM from the tarball.
> I also built both GHC 7.4.2 and 7.6.2 from source (release tarballs),
> both using the native back end.
I used LLVM backend (perf-llvm) for mine GHC 7.6.2.
I'm attaching some notes I made yesterday and today when I was investigating my
bu
urgh... really need to get a LLVM build bot up and running.
I'm tied up for next week or two so won't be able to address this
soon. Thanks though Austin for your work here and everyone else, great
to have the pain shared :).
Cheers,
David
On 14 March 2013 10:00, Geoffrey Mainland wrote:
> At le
Hi Gabor,
I can't comment specifically on your code, because I'm afraid I don't
understand it all. But, I think I can answer your question:
GHC will select a type instance branch to use in a given type family
application if and only if the following 2 conditions hold:
1. There is a substituti
On Thu, 2013-03-14 at 16:44 +, Simon Peyton-Jones wrote:
> Yes I think that'd be a great plan. It's bizarre that GHC depends on
> *all* of Cabal, but only uses a tiny part of it (more or less the
> Package data type I think).
The sensible way to split it (I think) would be like this:
cabal-l
At least they didn't re-roll the release tarball a second time :)
Would be good to confirm that we built from the same source tree. I am
building LLVM HEAD right now and will try that with GHC.
Geoff
On 03/14/2013 04:54 PM, Austin Seipp wrote:
> The LLVM 3.2 tarball has an annoying bug: it speci
The LLVM 3.2 tarball has an annoying bug: it specifies the version as
'3.2svn' and not 3.2. So it's kind of difficult to distinguish them.
You can verify this by downloading the 3.2 tarball from their website
and looking at autoconf's AC_INIT line:
$ pwd
/Users/a/Downloads/llvm-3.2.src
$ grep 3.2s
On 03/14/2013 04:40 PM, Jan Stolarek wrote:
>> If you type llc -version at the command line, it really says it's 3.2?
> You don't seem to believe me :)
Given that Austin and I have the stage 2 compiler failure and you don't,
I think it is reasonable do double check :)
> [killy@xerxes : ~] llc --v
Yes I think that'd be a great plan. It's bizarre that GHC depends on *all* of
Cabal, but only uses a tiny part of it (more or less the Package data type I
think).
Simon
| -Original Message-
| From: cabal-devel-boun...@haskell.org
[mailto:cabal-devel-boun...@haskell.org]
| On Behalf
> If you type llc -version at the command line, it really says it's 3.2?
You don't seem to believe me :)
[killy@xerxes : ~] llc --version
LLVM (http://llvm.org/):
LLVM version 3.2svn
Optimized build with assertions.
Built Mar 14 2013 (09:02:06).
Default target: x86_64-unknown-linux-gnu
H
Hi Richard,
I have a question regarding type families with overlapping syntax.
In below example the last two lines are overlapped, so the first gets selected
when I present type equality witness to GHC:
> help :: Sing (ls :: Inventory a) -> Sing (r :: Inventory a) -> Sing (l :: a)
> -> Sing (In
I just tried building your fingerprinted tree here two different ways,
and both failed:
GHC 7.4.2 as bootstrap compiler + LLVM 3.2
GHC 7.6.2 as bootstrap compiler + LLVM 3.2
If you type llc -version at the command line, it really says it's 3.2?
Geoff
On 03/14/2013 03:06 PM, Jan Stolarek wrote:
On Thu, 2013-03-14 at 12:22 -0300, Administrator wrote:
> This GHC dependency on Cabal is putting a rather troubling constraint
> in Cabal's evolution, which in my opinion is a serious problem. When I
> first took a look at the dependencies between GHC and Cabal I found it
> a bit strange that GHC
This GHC dependency on Cabal is putting a rather troubling constraint
in Cabal's evolution, which in my opinion is a serious problem. When I
first took a look at the dependencies between GHC and Cabal I found it
a bit strange that GHC would depend on Cabal as I would expect GHC to
be as low in the
On Thu, 2013-03-14 at 16:06 +0100, Gregory Collins wrote:
> On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts > wrote:
>
> > Hi folks,
> >
> > I want to give you advance notice that I would like to make Cabal depend
> > on parsec. The implication is that GHC would therefore depend on parsec
> > and
> Where are all the fingerprints for the libraries? You only seem to have
> the submodule libraries in there...
Whoops, I ran the fingerprint script in the build tree which doesn't have
symlinks to .git
directories. Is this version of the fingerprint correct?
Janek
.|56353e3da9d5718dfd25e25ccf
On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts wrote:
> Hi folks,
>
> I want to give you advance notice that I would like to make Cabal depend
> on parsec. The implication is that GHC would therefore depend on parsec
> and thus it would become a core package, rather than just a HP package.
> So t
Where are all the fingerprints for the libraries? You only seem to have
the submodule libraries in there...
Geoff
On 03/14/2013 03:00 PM, Jan Stolarek wrote:
> I'm attaching a fingerprint - is this OK?
>
> I'm quite puzzled about this, mostly because yesterday I couldn't build GHC
> using LLVM 3
On Thu, 2013-03-14 at 14:53 +, Duncan Coutts wrote:
> Hi folks,
>
> I want to give you advance notice that I would like to make Cabal depend
> on parsec. The implication is that GHC would therefore depend on parsec
> and thus it would become a core package, rather than just a HP package.
> So
I'm attaching a fingerprint - is this OK?
I'm quite puzzled about this, mostly because yesterday I couldn't build GHC
using LLVM 3.0 - I'm
attaching error messages in a separate file. It used to work about two weeks
ago when I used GHC
7.4.2 + LLVM 3.0 to build myself an optimized version of G
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than just a HP package.
So this would affect both GHC and the HP, though I hope not too much.
Glad to know I'm not crazy...
There is already a ticket #7694 about the failure bootstrapping with
LLVM 3.2.
Also, Jan, could you send a fingerprint of your build tree? You can use
utils/fingerprint/fingerprint.py to generate one. If your tree works and
ours doesn't, that might help us narrow dow
I was able to reproduce Geoffrey's failure on Mac OS X 10.8, with LLVM
3.2. The stage2 compiler eventually segfaults ("Segmentation Fault
11") during the build process after being compiled successfully with
stage1.
Something recently happened, because I was bootstrapping fine with
LLVM 3.2 recentl
> You don't have the following line?
>
> GhcLibWays = $(if $(filter $(DYNAMIC_BY_DEFAULT),YES),dyn,v)
I do. Sorry, I didn't notice it. I'm attaching my build.mk.
> What version of GHC are you using to perform the build?
[killy@xerxes : ~] ghc --version
The Glorious Glasgow Haskell Compilation Sys
On 03/14/2013 02:15 PM, Jan Stolarek wrote:
>> Hm, you're sure that LLVM 3.2 is in your path when you configure GHC?
> I removed LLVM 3.0 from my system so there's no possibility of
mistaking 3.2 with 3.0. I'm also
> getting lots of compilation warnings about untested LLVM version -
this didn't hap
> Hm, you're sure that LLVM 3.2 is in your path when you configure GHC?
I removed LLVM 3.0 from my system so there's no possibility of mistaking 3.2
with 3.0. I'm also
getting lots of compilation warnings about untested LLVM version - this didn't
happen with 3.0.
> This is HEAD?
Yes. Commit 56
On 03/14/2013 02:01 PM, Jan Stolarek wrote:
>> Has anyone gotten LLVM 3.2 to work with the quick-llvm BuildFlavour?
> Yes. I can do both quick-llvm and perf-llvm build with LLVM 3.2.
Surprisingly, yesterday I
> couldn't build GHC with LLVM 3.0 and I don't know why (it used to work).
>
> Janek
Hm,
> Has anyone gotten LLVM 3.2 to work with the quick-llvm BuildFlavour?
Yes. I can do both quick-llvm and perf-llvm build with LLVM 3.2. Surprisingly,
yesterday I
couldn't build GHC with LLVM 3.0 and I don't know why (it used to work).
Janek
___
ghc-de
36 matches
Mail list logo
