On Thu, May 31, 2012 at 2:41 AM, Ian Lynagh wrote:
> On Wed, May 30, 2012 at 08:44:26PM +1000, Tim Cuthbertson wrote:
>>
>> Configuring hsc2hs-0.67...
>> make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop.
>> make: *** [all] Error 2
>>
>> Any hints?
>
> That file should be inclu
On Wed, May 30, 2012 at 08:44:26PM +1000, Tim Cuthbertson wrote:
>
> Configuring hsc2hs-0.67...
> make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop.
> make: *** [all] Error 2
>
> Any hints?
That file should be included in the source tarball.
Thanks
Ian
___
On 12/19/08, Simon Marlow wrote:
>> lupus:~/ghc-6.8.3% ghc-6.8.3 -v
>> dyld: relocation error (external relocation for symbol
>> _pthread_mutex_unlock
>> in ghc-6.8.3 relocation entry 0 displacement too large)Trace/BPT trap
>>
>> Failure! ... or is it?
>
> I'd guess that the size of th
Uwe Hollerbach wrote:
Hello Barney & all, I've been following your messages with some
interest, as I too have been trying to build a more-modern ghc on my
G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and
tried to build 6.8.3; I'm finally at the point where I have something
to r
Hello Barney & all, I've been following your messages with some
interest, as I too have been trying to build a more-modern ghc on my
G3 iMac running 10.3.9. I started with an existing 6.6.1 build, and
tried to build 6.8.3; I'm finally at the point where I have something
to report, although I'm not
> The right place to add this would be in rts/package.conf.in, in extra-ld-
> opts, with suitable platform-specific #ifdefs. If you can whip up a
> patch and test it, I'll commit.
Here's the patch, which now compiles correctly.
diff -u a/rts/package.conf.in b/rts/package.conf.in
--- a/rts/package
Barney Stratford wrote:
I have a workaround for the linker bugs that keep popping up under Mac
OS X, and now have a working GHC 6.8. I found that saying -fasm didn't
help matters. Instead, on the assumption that the linker gets it wrong
and there is in fact nothing wrong with the object file, I
I have a workaround for the linker bugs that keep popping up under Mac
OS X, and now have a working GHC 6.8. I found that saying -fasm didn't
help matters. Instead, on the assumption that the linker gets it wrong
and there is in fact nothing wrong with the object file, I applied these
two patches:
On Mon, Nov 24, 2008 at 12:28:28PM +, Simon Peyton-Jones wrote:
> Ah hum. We probably have not compiled GHC 6.8 with 6.2 for some time.
> Worse, we don't even clearly document what the oldest version is that should
> bootstrap any given version.
>
> Ian: could you extend the building guide
> Do you have a link to something describing the problem?
This might be relevant: I don't know.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14612
Further useful information. The problem doesn't manifest itself when
compiling GHC 6.6, so the question is what parts of the runtime system
changed in t
Barney Stratford wrote:
The workaround is almost certainly to build the RTS with -fasm.
According to
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen,
-fasm is the default option anyway, or am I missing something here?
It looks like this is an issue wi
> On Monday 24 November 2008 23:15, Barney Stratford wrote:
>> There's good news and bad news. The good news is that the compilation of
>> my shiny almost-new GHC is complete. The bad news is, it won't link.
>> It's grumbling about
>>
>> ld:
>> /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/
> in the days of ghc-6.2, you got -fvia-C by default
The thing is, 6.2 is building 6.8 just fine. Stage 1 is quite happy. The
problem arises during linking of Stage 2 - ie 6.8 can't build itself.
Cheers,
Barney.
___
Glasgow-haskell-users mailing list
Gla
The suggested remedy of commenting out the
line reading "SRC_HC_OPTS += -fvia-C" in the Makefile won't work, as
that line isn't there anyway.
In case it is not obvious from what other people have said, way back
in the days of ghc-6.2, you got -fvia-C by default, whether it was
specified on t
> The workaround is almost certainly to build the RTS with -fasm.
According to
http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-codegen,
-fasm is the default option anyway, or am I missing something here?
It looks like this is an issue with the way Apple's versio
Barney Stratford wrote:
There's good news and bad news. The good news is that the compilation of
my shiny almost-new GHC is complete. The bad news is, it won't link.
It's grumbling about
ld:
/System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o)
has external relocation ent
Hello,
On Monday 24 November 2008 23:48, Barney Stratford wrote:
> > The heading seems to be: Your build is missing it's required GMP (GNU
> > Multiple Precision) library
> No, I have GMP installed, and it's correctly compiling against it. The
> issue isn't that these symbols are missing altogethe
> The heading seems to be: Your build is missing it's required GMP (GNU
> Multiple Precision) library
No, I have GMP installed, and it's correctly compiling against it. The
issue isn't that these symbols are missing altogether, but rather that
there's something wrong with them. It looks to me like
Hello,
On Monday 24 November 2008 23:15, Barney Stratford wrote:
> There's good news and bad news. The good news is that the compilation of
> my shiny almost-new GHC is complete. The bad news is, it won't link.
> It's grumbling about
>
> ld:
> /System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rt
There's good news and bad news. The good news is that the compilation of
my shiny almost-new GHC is complete. The bad news is, it won't link.
It's grumbling about
ld:
/System/Fink/src/fink.build/ghc-6.8.2-1/ghc-6.8.2/rts/libHSrts.a(PrimOps.o)
has external relocation entries in non-writable sectio
I can now confirm that 6.2 can, in fact, bootstrap 6.8.2 (with the
corrections to those hi-boots), although I've still not got the build to
complete. If anyone wants to see the patch file, then let me know and
I'll send it when I've ironed out the last creases.
Thanks to all those who helped out.
Ah hum. We probably have not compiled GHC 6.8 with 6.2 for some time. Worse,
we don't even clearly document what the oldest version is that should bootstrap
any given version.
Ian: could you extend the building guide
http://hackage.haskell.org/trac/ghc/wiki/Building (perhaps the "what tools y
Barney Stratford wrote:
I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the
typechecker refuses to compile. The problem seems to be that the hi-boot
files in compiler/typecheck contain some incorrect type signatures. I've
fixed most of them, but TcMatches.hi-boot-6 has slightly stu
Thanks for all the comments in this thread. I'm going to describe some
of the technical issues with making a GHC distribution that you can
bootstrap on any platform from a single set of sources below.
But first, let me explain our thinking on why we don't consider this a
priority: we aim to pro
On May 9, 2005, at 4:55 PM, Bennett Todd wrote:
2005-05-09T16:09:16 Daniel Carrera:
I think it should be if you want Haskell to grow in acceptance.
The first barrier that new potential users hit is the one that
causes most people to give up and move on to a different project.
That first barrier sho
On Mon, 2005-05-09 at 21:26 -0400, Mark Brooks wrote:
> I say this because I have been evaluating
> Haskell for use in my senior project. I need a stable and usable graphics
> toolkit for the project. While graphics toolkits for Haskell do exist, they
> are oftentimes either translations of ot
I think it should be if you want Haskell to grow in acceptance. The first
barrier that new potential users hit is the one that causes most people to
give up and move on to a different project. That first barrier should be
made as low as possible.
Without commenting on any of the other points rai
2005-05-09T16:09:16 Daniel Carrera:
> I think it should be if you want Haskell to grow in acceptance.
> The first barrier that new potential users hit is the one that
> causes most people to give up and move on to a different project.
> That first barrier should be made as low as possible.
This is
On 5/9/05, Daniel Carrera <[EMAIL PROTECTED]> wrote:
> I've been trying to learn Haskell.
Great... We are on the same boat :)
> I tried to compile GHC but it said taht it needed GHC to compile.
Yes, looks like GHC is a little picky to build, to say the least (i'm
working on OS X and i'm lucky,
On Mon, 2005-05-09 at 12:32 -0400, Daniel Carrera wrote:
> Duncan Coutts wrote:
>
> > This route is going to be your best bet. Find any binary version of ghc
> > that works on your Solaris and then from there you've broken the
> > GHC<->GHC dep cycle.
>
> Okay. Is there a version that's more like
Duncan Coutts wrote:
This route is going to be your best bet. Find any binary version of ghc
that works on your Solaris and then from there you've broken the
GHC<->GHC dep cycle.
Okay. Is there a version that's more likely to work than others? Or
should I try them sequentially from most recent, th
On Mon, 2005-05-09 at 09:54 -0400, Daniel Carrera wrote:
> Hello,
>
> I've been trying to learn Haskell.
>
> Some software isn't user friendly. But I think that a compiler requiring
> itself to compile is actively user hostile. I've spent over a week
> trying to get GHC to work on my Solaris wo
Simon Marlow wrote:
It is possible to compile GHC without having GHC installed, there are
detailed instructions in the Building Guide. Indeed you found the
instructions, but gave up because the instructions talked about
"porting". So is that all you're complaining about?
No, you misunderstood. I
On 09 May 2005 16:03, Daniel Carrera wrote:
> robert dockins wrote:
>
>> Perhaps. Nonetheless it is common practice for compilers to be
>> written in the target language and to be compiled via bootstrapping.
>> Ever take a look at the GCC sources? You guessed it: C.
>
> Please don't confuse th
Daniel Carrera writes:
> It's not often that it takes me more than a week to
> compile a program.
You should have posted a short message to the list, asking
whether anyone happened to have a tar.gz archive with
Solaris binaries lying around that he can send you. I'm
willing to bet that would ha
On 10/05/2005, at 1:03 AM, Daniel Carrera wrote:
You can compile gcc with Sun's CC. You should be able to compile
ghc with nh98.
Unfortunately, GHC isn't written in standard Haskell 98: GHC's
written in Haskell 98 with GHC extensions, sometimes referred to as
"Glasgow Haskell". You can proba
robert dockins wrote:
Perhaps. Nonetheless it is common practice for compilers to be written
in the target language and to be compiled via bootstrapping. Ever take
a look at the GCC sources? You guessed it: C.
Please don't confuse the compiler being written in the target language
with the com
Well Robert Dockins gave you an excellent explanation.
You're just unlucky at the moment with 6.4. 6.2.2 is excellent -
for various reasons I've had to stick with it for completion of some
of my research.
>Having the compiler able to compile itself, yes. Making that the only
>way to compile it, t
Andrew Cheadle wrote:
:-p ok,ok, lots of people (but will they really continue to - we
dropped it from our labs long ago). Having said that, how many
people don't have access to a Windoze or Linux
I don't have access to Win or Linux. But that's besides the point. I
think it's reasonable to expect
robert dockins addresses this to -
Daniel Carrera wrote:
Hello,
I've been trying to learn Haskell.
...
At this point I decide that I'll teach people Python instead of
Haskell. I don't particularly like Python, but hey, it works.
Your choice, of course.
I'll say more. You may buy to your kids
Daniel Carrera wrote:
Hello,
I've been trying to learn Haskell.
Some software isn't user friendly. But I think that a compiler requiring
itself to compile is actively user hostile.
Perhaps. Nonetheless it is common practice for compilers to be written
in the target language and to be compiled vi
Daniel
While I'm sure many understand and sympathise with your pain I wonder if
you're being a little harsh.
I mean
who's really using Solaris these days?
:-p ok,ok, lots of people (but will they really continue to - we
dropped it from our labs long ago). Having said that, how many
people don'
On Sun, 25 Jun 2000, Sven Panne wrote:
> Sven Panne wrote:
> > [...] This has been fixed for 4.07, but as people are supposed to be
> > able to build 4.07 with pre-4.07 compilers, I'll change those
> > identifiers in the driver sources with something more defensive.
>
> I've just realised that t
Sven Panne <[EMAIL PROTECTED]> writes:
> Sven Panne wrote:
> > [...] This has been fixed for 4.07, but as people are supposed to be
> > able to build 4.07 with pre-4.07 compilers, I'll change those
> > identifiers in the driver sources with something more defensive.
>
> I've ju
I think it's a legitimate problem with the new driver. I hit it myself
on Friday. I think that the _Capitalised entity naming scheme is
being misinterpreted by pre-4.07 ghc's.
... and I see that Sven has already fixed it. Cool.
J
Sven Panne wrote:
> [...] This has been fixed for 4.07, but as people are supposed to be
> able to build 4.07 with pre-4.07 compilers, I'll change those
> identifiers in the driver sources with something more defensive.
I've just realised that this is not the true story. You *can* build
4.07 with
Jens-Ulrik Petersen wrote:
> For some time I haven't been able to compile ghc from cvs. [...]
> What's going wrong? [...]
> Config.hs:2: Data constructor not in scope: `_ProjectName' [...]
Until recently (including 4.06) GHC confused variables having names
starting with an underscore followed by
47 matches
Mail list logo
