Re: os x 64-bit?

[Gregory Wright]

Hi,

I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard.  Much of the work
in getting ghc to build 64-bit was done by Barney Stratford; the MacPorts
ghc 6.10.4 has built successfully in 64 bit mode for a number of months.

Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit because
of changes in ghci.  These changes were in part to remove the limitation 
that modules
loaded by ghci had to be located below the 2 GB address boundary.  
Unfortunately,

they revealed code paths in ghc's Mach-O linker that were never tested. (See
bug #4318. Other bugs may be partial duplicates; the tickets probably need
to be examined to check which ones are distinct.)

The good news is that the linker patches were done just in time for 7.0.1.
You should be all set to try the release candidates on Snow Leopard 64-bit.

I built my 7.0.1-rc2 using a 64 bit 6.10.4.  My original 64-bit 6.10.4 
was bootstrapped

using a 32-bit 6.10.4 compiled on Leopard.  Reports of trouble building the
7.0.1 release candidates using a 32-bit bootstrap compiler would be 
especially

useful.

Best Wishes,
Greg


On 11/9/10 12:48 PM, Brian Bloniarz wrote:

On 11/09/2010 02:36 AM, John Lato wrote:

I was wondering if there is a status report anywhere of progress towards
making ghc compile 64-bit on Snow Leopard.  There are a few trac tickets
that seem related:

I think http://hackage.haskell.org/trac/ghc/ticket/3472
is related if you haven't seen it.

I'm not working on this, though I am interested in helping enable
cross-compilation of GHC in general. I have been working on one facet
though: hsc2hs. hsc2hs is one of barriers to cross-compilation because
it requires compiling and running a .c file on the target machine
(because it needs target-specific information like the layout of
structures; GHC's mkDerivedConstants also has the same problem).

I have a proof-of-concept patch which can do hsc2hs codegeneration
without running anything. This uses the same approach that autoconf
uses for cross-compilation. I'll try to post it within the next few
days -- if anybody finds this approach interesting please let me know.

Thanks,
-Brian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: os x 64-bit?

[Gregory Wright]

On 11/10/10 10:44 AM, Antoine Latter wrote:

On Wed, Nov 10, 2010 at 9:04 AM, Gregory Wright  wrote:

Hi,

I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard.  Much of the work
in getting ghc to build 64-bit was done by Barney Stratford; the MacPorts
ghc 6.10.4 has built successfully in 64 bit mode for a number of months.

Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit because
of changes in ghci.  These changes were in part to remove the limitation
that modules
loaded by ghci had to be located below the 2 GB address boundary.
  Unfortunately,
they revealed code paths in ghc's Mach-O linker that were never tested. (See
bug #4318. Other bugs may be partial duplicates; the tickets probably need
to be examined to check which ones are distinct.)

The good news is that the linker patches were done just in time for 7.0.1.
You should be all set to try the release candidates on Snow Leopard 64-bit.

I built my 7.0.1-rc2 using a 64 bit 6.10.4.  My original 64-bit 6.10.4 was
bootstrapped
using a 32-bit 6.10.4 compiled on Leopard.  Reports of trouble building the
7.0.1 release candidates using a 32-bit bootstrap compiler would be
especially
useful.

Are there any instructions for building in this fashion from the
source tarball or from VCS?

Antoine




Hi Antione,

I used the tarball ghc-7.0.0.20101028.tar.bz2 and followed the 
directions in the README file:


$ perl boot
$ ./configure
$ make

(The "perl boot" command wasn't necessary, since I was building from a 
tarball instead

of a darcs pull.  However, it didn't cause any problems.)

I haven't run a testsuite on the build yet.  Perhaps someone from 
haskell HQ can

tell me which version of the tests I should run on 7.0.1-rc2?

Best Wishes,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Glasgow-haskell-users] os x 64-bit?

[Gregory Wright]

Hi John,

I'll take a look at trac #2965.  You should be able to build the 
7.0.1-rc2 tarball
simply by unpacking it and following the instructions in the README.  
(In short,

configure, make then make install ought to work.)

If it doesn't build properly out of the box, I'd be interested in 
hearing about it.
AFAIK, only 6.10.4 has been tested as bootstrap compiler for 7.0.1-rc2, 
although
I expect 6.12.3 should work too.  There is always the possibility of 
some hiccup,

however.

Best Wishes,
Greg


On 11/11/10 6:17 AM, John Lato wrote:

Hi Greg,

Thanks very much for all your work on this, and Barney Stratford too. 
 This is great news.  I'm doing a lot of numerical work with Doubles 
at the moment, so progress is quite welcome!


I can try building 7.0.1-RC using a 32-bit 6.12.3, although probably 
not until the weekend.  I'll let you know how it goes.


If there are any special build instructions for this, maybe you could 
update trac #2965 with details?

Cheers,
John

From: Gregory Wright mailto:gwri...@antiope.com>>

Hi,

I built ghc 7.0.1-rc2 yesterday 64-bit on Snow Leopard.  Much of
the work
in getting ghc to build 64-bit was done by Barney Stratford; the
MacPorts
ghc 6.10.4 has built successfully in 64 bit mode for a number of
months.

Until just a few weeks ago 6.12.x and HEAD wouldn't build 64-bit
because
of changes in ghci.  These changes were in part to remove the
limitation
that modules
loaded by ghci had to be located below the 2 GB address boundary.
Unfortunately,
they revealed code paths in ghc's Mach-O linker that were never
tested. (See
bug #4318. Other bugs may be partial duplicates; the tickets
probably need
to be examined to check which ones are distinct.)

The good news is that the linker patches were done just in time
for 7.0.1.
You should be all set to try the release candidates on Snow
Leopard 64-bit.

I built my 7.0.1-rc2 using a 64 bit 6.10.4.  My original 64-bit 6.10.4
was bootstrapped
using a 32-bit 6.10.4 compiled on Leopard.  Reports of trouble
building the
7.0.1 release candidates using a 32-bit bootstrap compiler would be
especially
useful.

Best Wishes,
Greg


On 11/9/10 12:48 PM, Brian Bloniarz wrote:
> On 11/09/2010 02:36 AM, John Lato wrote:
>> I was wondering if there is a status report anywhere of
progress towards
>> making ghc compile 64-bit on Snow Leopard.  There are a few
trac tickets
>> that seem related:
> I think http://hackage.haskell.org/trac/ghc/ticket/3472
> is related if you haven't seen it.
>
> I'm not working on this, though I am interested in helping enable
> cross-compilation of GHC in general. I have been working on one
facet
> though: hsc2hs. hsc2hs is one of barriers to cross-compilation
because
> it requires compiling and running a .c file on the target machine
> (because it needs target-specific information like the layout of
> structures; GHC's mkDerivedConstants also has the same problem).
>
> I have a proof-of-concept patch which can do hsc2hs codegeneration
> without running anything. This uses the same approach that autoconf
> uses for cross-compilation. I'll try to post it within the next few
> days -- if anybody finds this approach interesting please let me
know.
>
> Thanks,
> -Brian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC7 (on OSX.5)

[Gregory Wright]

On 3/21/11 4:16 AM, Christian Maeder wrote:

Am 20.03.2011 20:01, schrieb wren ng thornton:

So I'm having a go of installing ghc-7.0.2 and
haskell-platform-2011.2.0.0 on OSX 10.5. Since 10.5 is no longer
supported I've had to compile from source. The good news is, so far as I
can tell, everything works right out of the box.[1]


[...]


[1]
OSX 10.5.8
arch x86_64 (though it calls itself i386)


Does your ghc-7.0.2 create 32 or 64 bit Code? What does "ghc --info" say?


Xcode 3.1.2 (not that it matters)
gcc 4.0.1 (i686-apple-darwin9-gcc-4.0.1 Apple Inc. build 5490)
ghc 6.12.1 / hp 2010.1.0.0


As far as I know there was no 64bit ghc-6.12.x for MacOS. Is it 
possible to create a 64bit ghc starting with a 32Bit ghc? I don't 
think so and always used ghc-6.10.4 from macports to create 64bit 
binary-dists that have the suffix -x86_64-apple-darwin.tar.bz2 rather 
than -i386-apple-darwin.tar.bz2 for 32bit compilers.




There was never a 64 bit 6.12.3 for OS X.  I tried for a while to patch 
6.12.3
to make a MacPorts release, but it became clear that there were many 
problems,
and that it would be better to contribute fixes to ghc to support O X 64 
bit.


7.0.2 is the first release that works (mostly) on OS X 64 bit.  It still 
fails significantly
more regression tests than on 64 bit linux (around 80 tests instead of 
around 10).

On the other hand we won't get the remaining bugs out without more people
trying it out.

I've started to work on updating the ghc portfile to 7.0.2.  There will 
be many fewer
patches, but there are still some questions about what to do (should 
support for
forcing a 32 bit build on a 64 bit platform be retained) and quite a bit 
of testing is

needed.  However, I need to upgrade my own development environment to
7.0.2, so I have some incentive to get the work done.

In the MacPorts version I may include my runtime linker debug patch, 
which won't
be available generally until 7.2.1.  If more linker problems are 
suspected, this

would give a complete view of what the linker was doing.

Best,
Greg

--
Gregory Wright
Antiope Associates LLC
18 Clay Street
Fair Haven, New Jersey 07733
USA

+1 732 924-4549 [office]
+1 732 345-8378 [fax]
gwri...@antiope.com


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Progress building unregisterised for FreeBSD/amd64

[Gregory Wright]

Hi Ian,

I have made some progress.  Today I got 6.4.2 to build unregisterized on
my FreeBSD/amd64 box.  I went back to 6.4.2 because the only actual  
report

of success I could find record of was Wilhelm Kloke's.  He used 6.4.1.

I made certain I had exactly the same versions of readline and gmp on  
both
machines.  This might not be necessary, but it's one less thing that  
might
go wrong.  I also downgraded my ghc to 6.4.2 on the host i386  
system.  Building
6.4.2 using 6.6 runs into trouble with the change in the mutable  
array API.


The 6.4.2 build now runs successfully to the end of the hc-build script.
I haven't installed it, but tried to build an out of the box 6.6 with  
the 6.4.2
ghc-inplace.  (I applied my patch to Linker.c so that the build  
wouldn't fail
merely because of undefined symbols.)  I also patched the mangler by  
adding

"|freebsd" to rules for /^x86_64-.*-(linux|openbsd)$/.

The interesting thing is that out of the box using the 6.4.2  
bootstrap compiler,
6.6 still crashes when compiling Linker.c.  Not just a little crash;  
it hung the

whole system.  At that point it is using the ghc-inplace of 6.6.

On Mar 13, 2007, at 3:05 PM, Ian Lynagh wrote:



This sounds like you are using the original 6.6? You're probably  
better
off trying to start from the 6.6 darcs branch instead (make a  
tarball of

a checkout (might as well run autoreconf first) so you can be sure you
have the same source on both machines).



As I said, I'm using out of the box 6.6.  Should I try a 6.6 from darcs?



../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-
prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -
optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-
I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-
fomit-frame-pointer -optc-fno-strict-aliasing -H16m -O -optc-O2 -
static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c  
Linker.c -

o Linker.o
Segmentation fault (core dumped)
gmake: *** [Linker.o] Error 139
gmake: Leaving directory `/tmp/ghc-6.6/rts'


../compiler/ghc-inplace has successfully compiled other files by this
point, right?



Yes.  I've built the 6.6 compiler with the 6.4.2 bootstrap, and the  
inplace
6.6 has built everything up until Linker.c.  Then crash, burn,  
smoking ruin.



It probably won't help, but what does it say if you add -v?

I suspect the next step is to try gdb and see what it says, though. It
might be necessary to repeat the build with -g -O0 in GhcHcOpts or  
other

variables (be wary of hc-build trampling changes you make to
mk/build.mk).

It might even be useful to tweak the process so that you end up with a
-debug ghc (in fact, this should probably be the default). I don't  
have
instructions for how to do this, but I've done it in the past and  
don't
remember any major difficulties. Basically stick "SRC_HC_OPTS += - 
debug"

in compiler/Makefile and fix any problems that come up (you might need
to do things like "make WAY=debug" in rts/, and modify the list of  
files

that get put in the tarball).




I can add -v.  Should I try to build a vanilla 6.6 with debugging or  
one out

of darcs?  Which would be more useful?

Thanks for your help.



Thanks
Ian



Best Wishes,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

FreeBSD/amd64 port: more progress

[Gregory Wright]

Hi Ian,

I'm building ghc-6.6.20070314 using the unregisterized ghc-6.4.2.
(BTW, the unregisterized 6.4.2 seems quite reliable.  I was able to
build happy-1.15 and alex-2.0.1 without any problem.)

I configured 6.6.20070314 for debugging by putting

GhcUnregisterised=YES
GhcWithNativeCodeGen=NO
GhcWithInterpreter=NO
SplitObjs=NO
GhcWithSMP=NO
SRC_HC_OPTS+=-debug -L/usr/local/lib
GhcRTSWays=debug
GhcRtsHcOpts+=-optc-DDEBUG
GhcRtsCcOpts+=-optc-g
EXTRA_LD_OPTS=-L/usr/local/lib -lbfd -liberty

in mk/build.mk.  With debugging turned on, the new 6.6
no longer hangs when compiling rts/Linker.c, rather the new
6.6 ghc-inplace fails compiling the first file it tries, Adjustor.c.

I was running "top -u" in another window and when the build
failed the memory used went unprintably high (i.e., "top" couldn't
print it, nor could you print what I said when I noticed this).

I was able to re-run the failed compilation under gdb.  I added
"-v" to ghc's command line.  The big slowdown seemed to occur while
ghc-inplace was generating the command line for the c compiler.
This is when I interrupted it.  From gdb:


(gdb) run -B/tmp/ghc -optc-O -optc-Wall -optc-W -optc-Wstrict- 
prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations - 
optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- 
I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc- 
fomit-frame-pointer -optc-optc-g -optc-DNOSMP -optc-I/usr/local/ 
include -optc-fno-strict-aliasing -H16m -O -debug -L/usr/local/lib - 
optc-O2 -optc-DDEBUG -optc-DNOSMP -static -I/usr/local/include -I. - 
#include HCIncludes.h -fvia-C -dcmm-lint -v-c Adjustor.c -o  
Adjustor.o
Starting program: /tmp/ghc/compiler/stage1/ghc-6.6.20070314 -B/tmp/ 
ghc -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc- 
Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- 
Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc- 
I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer - 
optc-optc-g -optc-DNOSMP -optc-I/usr/local/include -optc-fno-strict- 
aliasing -H16m -O -debug -L/usr/local/lib -optc-O2 -optc-DDEBUG -optc- 
DNOSMP -static -I/usr/local/include -I. -#include HCIncludes.h -fvia- 
C -dcmm-lint -v-c Adjustor.c -o Adjustor.o
Glasgow Haskell Compiler, Version 6.6.20070314, for Haskell 98,  
compiled by GHC version 6.4.2

Using package config file: /tmp/ghc/driver/package.conf.inplace
wired-in package base not found.
wired-in package rts mapped to rts-1.0
wired-in package haskell98 not found.
wired-in package template-haskell not found.
Hsc static flags: -funregisterised -static -static
Created temporary directory: /tmp/ghc27577_0
*** C Compiler:
gcc -x c Adjustor.c -o /tmp/ghc27577_0/ghc27577_0.s -v -S -Wimplicit - 
O -D__GLASGOW_HASKELL__=606 -DNO_REGS -DUSE_MINIINTERPRETER -O -Wall - 
W -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations - 
Winline -Waggregate-return -Wbad-function-cast -I../includes -I. - 
Iparallel -DCOMPILING_RTS -fomit-frame-pointer -optc-g -DNOSMP -I/usr/ 
local/include -fno-strict-aliasing -O2 -DDEBUG -DNOSMP -I /usr/local/ 
include -I . -I /tmp/ghc/includes -fwrapv

Using built-in specs.
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
/usr/libexec/cc1 -quiet -v -I../includes -I. -^C
Program received signal SIGINT, Interrupt.
0x015b56f3 in findMBlockMap (p=0x3a24270) at MBlock.c:68
68  for( i = 0; i < mblock_map_count; i++ )
(gdb) bt
#0  0x015b56f3 in findMBlockMap (p=0x3a24270) at MBlock.c:68
#1  0x015b574b in markHeapAlloced (p=0x3a24270) at  
MBlock.c:98

#2  0x015b59df in getMBlocks (n=262145) at MBlock.c:280
#3  0x015ac617 in allocMegaGroup (n=262145) at BlockAlloc.c:174
#4  0x015ac3e0 in allocGroup (n=67108865) at BlockAlloc.c:72
#5  0x0159e24a in allocate (n=34359738372) at Storage.c:504
#6  0x0159e439 in allocatePinned (n=34359738372) at Storage.c: 
593

#7  0x015a1376 in newPinnedByteArrayzh_fast ()
#8  0x0159d3e2 in StgRun (f=0x15a1330  
,

basereg=0x3a2) at StgCRun.c:93
#9  0x015990f3 in schedule (mainThread=0x2164080,
initialCapability=0x3a2) at Schedule.c:932
#10 0x01599edd in waitThread_ (m=0x2164080,  
initialCapability=0x0)

at Schedule.c:2156
#11 0x01599dd3 in scheduleWaitThread (tso=0x801dc, ret=0x0,
initialCapability=0x0) at Schedule.c:2050
#12 0x015959b1 in rts_evalLazyIO (p=0x1931270, ret=0x0) at  
RtsAPI.c:459
#13 0x0159521f in main (argc=1114636288, argv=0x3a2) at  
Main.c:104

(gdb) f 0
#0  0x015b56f3 in findMBlockMap (p=0x3a24270) at MBlock.c:68
68  for( i = 0; i < mblock_map_count; i++ )


Looks like someone is asking for too much memory (n=34359738372)!

I've taken a cursory look at this, but I wanted to send a note in  
case you

know what is wrong off the top of your head.

I'll be away next week so I won't 

Re: FreeBSD/amd64 port: more progress

[Gregory Wright]

Hi Ian,

On Mar 15, 2007, at 12:21 PM, Ian Lynagh wrote:



I think the first thing to do is to see if  
newPinnedByteArrayzh_fast is

being passed plausible values. The easiest way is probably to set a
breakpoint in gdb on newPinnedByteArrayzh_fast (Having
"GhcRtsHcOpts += -keep-hc-files" in mk/build.mk will probably help so
you can look at PrimOps.hc; unfortunately we don't seem to set hcsuf -
we probably should. You might also want to check that the RTS wasn't
compiled with optimisation on. Note that this is in the 6.4 tree, not
the 6.6 one!)



The 6.4.2 compiler was built with by the hc-build script which uses

GhcWithInterpreter=NO
GhcWithNativeCodeGen=NO
SplitObjs=NO
GhcLibWays=

in build.mk, so I assume it has optimization on.  Can I simply add

GhcRtsHcOpts += -O0

or should I change SRC_HC_OPTS with

SRC_HC_OPTS += -O0

in the build.mk of the 6.4.2 tree?  I'm also assuming that I can
just rebuild 6.4.2 with optimization off on the target amd64 box
and that I can still use my original .hc files from the i386 machine.
Is that true?


If you do make any changes to the RTS code or compilation options then
you'll have to run make and make install in 6.4.2's rts/, then delete
6.6-branch's compiler/stage1/ghc-6.6* and run make stage=1 in  
compiler/.




Oakey-dokey.



Thanks
Ian



Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FreeBSD/amd64 port: more progress

[Gregory Wright]

Hi Ian,

On Mar 15, 2007, at 6:06 PM, Ian Lynagh wrote:


On Thu, Mar 15, 2007 at 05:15:02PM -0400, Gregory Wright wrote:


in build.mk, so I assume it has optimization on.  Can I simply add

GhcRtsHcOpts += -O0

or should I change SRC_HC_OPTS with

SRC_HC_OPTS += -O0

in the build.mk of the 6.4.2 tree?





On the other hand, if you mean you're going to do another complete  
build

then you may as well make everything non-optimised now rather than
wishing you'd done so later.



Yes, I was just going to do a complete rebuild with everything  
nonoptimized.
It doesn't take too long on the new 2.4 GHz dual two core Opteron  
box :-)


(Although I am careful to turn off SMP and not try a parallel make,  
greed being

one of the deadly sins.)

BW,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

More on FreeBSD/amd64

[Gregory Wright]

Hi Ian,

I have made some more progress on understanding the build
failure on FreeBSD/amd64.  I could use a check on my understanding
of the problem, though.

The setup:  I have an unregisterized ghc-6.4.2 successfully built
on FreeBSD/amd64.  It was bootstrapped from .hc files compiled
on FreeBSD/i386.  I am attempting to use this compiler (the ghc-inplace
from the unregisterized build, not a fully installed compiler) to
build a recent ghc-6.6 branch from darcs (20070314).

The build of ghc-6.6-20070314 fails when compiling rts/Linker.c.
The failure is mostly reproducible (more about that below).

It's also worth remembering that when I tried to build an unregisterized
ghc-6.6 on FreeBSD/amd64 using .hc files from ghc-6.6 built on  
FreeBSD/i386,

I had a crash at the same place, while trying to build rts/Linker.c

The failure comes from trying to allocate a huge amount of memory.
newPinnedByteArrayzh_fast is called with a giant argument, 0x400010.
So it looks like we're after 16 bytes, but the upper 32 bits has some
junk in it.

The above was the state of things just over a week ago.  Since then,
I've worked to track down whether the bug is in the ghc-6.4.2 runtime
or in the ghc-6.6 code.  The compiler that fails is the 6.6 stage1
compiler, which is a 6.6 compiler linked with the runtime from the
unregisterized 6.4.2 (let me know if I'm wrong about that).

I have rebuilt the unregisterized 6.4.2 with optimization turned off.
I haven't got any more information this way; it seems the problem is
really on the 6.6 side.  Here is my reasoning:

I run the 6.6 compiler under the debugger:


greenhouse-george> gdb /tmp/ghc/compiler/stage1/ghc-6.6.20070314
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.

This GDB was configured as "amd64-marcel-freebsd"...
(gdb) dir /tmp/ghc-6.4.2/ghc/rts
Source directories searched: /tmp/ghc-6.4.2/ghc/rts:$cdir:$cwd
(gdb) b newPinnedByteArrayzh_fast
Breakpoint 1 at 0x163cbb4
(gdb) run -B/tmp/ghc -v  -optc-O -optc-Wall -optc-W -optc-Wstrict- 
prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations - 
optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc- 
I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc- 
fomit-frame-pointer -optc-I/usr/local/include -optc-fno-strict- 
aliasing -H16m -O -optc-O2 -static -I/usr/local/include -I. -#include  
HCIncludes.h -fvia-C -dcmm-lint -c Linker.c -o Linker.o
Starting program: /tmp/ghc/compiler/stage1/ghc-6.6.20070314 -B/tmp/ 
ghc -v  -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc- 
Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc- 
Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc- 
I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer - 
optc-I/usr/local/include -optc-fno-strict-aliasing -H16m -O -optc-O2 - 
static -I/usr/local/include -I. -#include HCIncludes.h -fvia-C -dcmm- 
lint -c Linker.c -o Linker.o


Breakpoint 1, 0x0163cbb4 in newPinnedByteArrayzh_fast ()


By playing around with it, I have isolated --- more or less --- when the
failure occurs.  In this run, it was after 973 calls to  
newPinnedByteArrayzh_fast.
If I quit gdb and re-run it, the number of calls is consistently the  
same.
However, from one system boot to the next, it varies a bit.   
Yesterday morning,

I had to skip 976 calls.


(gdb) c 973
Will ignore next 972 crossings of breakpoint 1.  Continuing.
Glasgow Haskell Compiler, Version 6.6.20070314, for Haskell 98,  
compiled by GHC version 6.4.2

Using package config file: /tmp/ghc/driver/package.conf.inplace
wired-in package base not found.
wired-in package rts mapped to rts-1.0
wired-in package haskell98 not found.
wired-in package template-haskell not found.
Hsc static flags: -static -static
Created temporary directory: /tmp/ghc1073_0
*** C Compiler:
gcc -x c Linker.c -o /tmp/ghc1073_0/ghc1073_0.s -v -S -Wimplicit -O - 
D__GLASGOW_HASKELL__=606 -O -Wall -W -Wstrict-prototypes -Wmissing- 
prototypes -Wmissing-declarations -Winline -Waggregate-return -Wbad- 
function-cast -I../includes -I. -Iparallel -DCOMPILING_RTS -fomit- 
frame-pointer -I/usr/local/include -fno-strict-aliasing -O2 -I /usr/ 
local/include -I . -I /tmp/ghc/includes -fwrapv


Breakpoint 1, 0x0163cbb4 in newPinnedByteArrayzh_fast ()


OK, I should be at the call which is going to blow up:


(gdb) bt
#0  0x0163cbb4 in newPinnedByteArrayzh_fast ()
#1  0x016377ea in StgRun (f=0x163cbb0  
,

basereg=0x260fcd0) at StgCRun.c:93
#2  0x01631f48 in schedule (mainThread=0x2611080,
initialCapability=0x0) at Schedule.c:932
#3  0x01633190 in waitThread_ (m=0x2611080,  
initialCapability=0x0)

at S

Re: More on FreeBSD/amd64

[Gregory Wright]

Hi SImon,

On Mar 29, 2007, at 5:40 AM, Simon Marlow wrote:


Hi Greg,

Good analysis so far.  I think you're close to this one.



Thank you for checking over what I've done thus far.

Based on what you said, I looked at Compat.Unicode and there is  
indeed a type error in this foreign call:


foreign import ccall unsafe "u_gencat"
  wgencat :: CInt -> Int

The return type should be CInt, not Int.  Try changing that and see  
if it helps.  You might need to add some fromIntegrals.




I noticed this too yesterday and tried correcting it this morning.   
Changing the return
type from Int to CInt didn't help.  The problem will no doubt be  
subtle, yet
entirely obvious in retrospect.  I'll try to get some time to work on  
it in the next

few days.

It's still a bit puzzling why this problem affects FreeBSD, and  
apparently not Linux.

Differences in header files?


Cheers,
Simon


Best Wishes,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: More on FreeBSD/amd64

[Gregory Wright]

Hi Ian,

On Mar 30, 2007, at 8:22 AM, Ian Lynagh wrote:


On Fri, Mar 30, 2007 at 09:31:07AM +0100, Simon Marlow wrote:

Ian Lynagh wrote:


OK, so we know that the wrong value is being passed to
newPinnedByteArray#, right? There aren't many calls to that:

   libraries/base/Foreign/Marshal/Alloc.hs
   libraries/base/GHC/ForeignPtr.hs (4 calls)
   libraries/base/GHC/Handle.hs


Oh, I've just realised, it's the 6.4.2 libraries you need to look at,
not the 6.6 ones.


Let me make sure I understand this:  the problem show up
when running the 6.6 compiler in compiler/stage1/ghc-6.6-20070314.
This compiler is linked with the ghc-6.4.2 RTS  _and_ the ghc-6.4.2
libraries, correct?

So when I look for symbols mentioned in the RTS stack, (e.g.,  
"s311_info") I have
to refer to the -ddump-stg output from the ghc-6.4.2 build. Is this  
true?




so the easiest way forward is probably to print something unique,  
and

the size passed, in each one and try to work backwards towards the
source. e.g.


Or just single-step (by *instruction*, not line) from an earlier  
point
before the crash.  I think Greg was stepping by line before, which  
is why

he didn't see anything happen before the erroneous call.


If you're going to try this then I find it easier with

GhcLibHcOpts += -O0 -g

when building the (6.4.2) libraries.


Yes, I did this.

Thank you for your help!

Best Wishes,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] ghc-6.7.20070330 on Mac OS X

[Gregory Wright]

Hi Ruben,

The GHC wiki also has information on this, and should be your first
stop if you are experiencing build problems:

http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX

At least under MacPorts, I have had no trouble building 6.7-20070330.
I will be releasing a new portfile for ghc-devel in a few days that will
build the latest from the darcs repository.

Best Wishes,
Greg

On Apr 1, 2007, at 11:50 AM, Pepe Iborra wrote:


(redirecting to glasgow-haskell-users)

It is well known that the readline lib that comes with OS X is no  
good, and you need to use a replacement. A nice post from the  
blogosphere explaining all this:


http://mult.ifario.us/articles/2006/10/17/ghc-6-6-and-mac-os-x- 
readline-quick-fix


If that doesn't help, please post the errors that you get when  
building the readline package.


Cheers
pepe



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: More on FreeBSD/amd64

[Gregory Wright]

Hi Ian,

On Mar 29, 2007, at 8:36 PM, Ian Lynagh wrote:



Hmm, oh well.

OK, so we know that the wrong value is being passed to
newPinnedByteArray#, right? There aren't many calls to that:

libraries/base/Foreign/Marshal/Alloc.hs
libraries/base/GHC/ForeignPtr.hs (4 calls)
libraries/base/GHC/Handle.hs

so the easiest way forward is probably to print something unique, and
the size passed, in each one and try to work backwards towards the
source. e.g.

mallocPlainForeignPtrBytes (I# size) = IO $ \s ->
case newPinnedByteArray# size s  of { (# s, mbarr# #) ->

=>

mallocPlainForeignPtrBytes i@(I# size) = do
  print ('A', i)
  IO $ \s ->
case newPinnedByteArray# size s  of { (# s, mbarr# #) ->

(it might be worth printing something after the existing IO action as
well, just to avoid confusion as to what is happening.




Is there a version of "print" I can use for debugging these libraries?
Just adding "print" causes a cycle in module dependencies.

I can now start gdb instruction stepping close to the crash and it looks
as if the trouble comes from mallocForeignPtr.  I'm trying to find out
what calls that now.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: More on FreeBSD/amd64

[Gregory Wright]

Hi Ian,

On Apr 1, 2007, at 3:57 PM, Ian Lynagh wrote:



Hi Gregory,

Is there a version of "print" I can use for debugging these  
libraries?

Just adding "print" causes a cycle in module dependencies.


Ah, remove the #if/#endif around the definition of "puts", its export,
and the GHC.Pack import in libraries/base/GHC/Handle.hs

No such luck.  I even copied "puts" into libraries/base/GHC/ 
ForeignPtr.hs

but I still get I cycle because I need withCString to define "puts":

Module imports form a cycle for modules:
  GHC.ForeignPtr
imports: GHC.Show GHC.Err GHC.Ptr GHC.IOBase GHC.Base GHC.List
 Foreign.Storable Foreign.Ptr Foreign.C Control.Monad
  Foreign.C imports: Foreign.C.Error Foreign.C.String Foreign.C.Types
  Foreign.C.Error
imports: GHC.Base GHC.Num GHC.IOBase Data.Maybe
 Foreign.Marshal.Error Foreign.C.String Foreign.C.Types  
Foreign.Ptr

 Foreign.Storable GHC.IOBase
  Foreign.C.String
imports: GHC.Base GHC.IOBase GHC.Num GHC.Real GHC.List Data.Word
 Foreign.Storable Foreign.Ptr Foreign.C.Types  
Foreign.Marshal.Array

  Foreign.C.Types
  Data.Typeable
imports: GHC.Arr GHC.Stable GHC.ForeignPtr GHC.Ptr GHC.STRef GHC.ST
 GHC.IOBase GHC.IOBase GHC.Real GHC.Float GHC.Num  
GHC.Err GHC.Show
 GHC.Base Data.List Data.Word Data.Int Data.Either  
Data.Maybe

 Data.HashTable
  Foreign.Marshal.Array
imports: GHC.Base GHC.Err GHC.List GHC.Num GHC.IOBase
 Foreign.Marshal.Utils Foreign.Marshal.Alloc  
Foreign.Storable

 Foreign.Ptr Control.Monad
  Foreign.Marshal.Utils
imports: GHC.Base GHC.Num GHC.Real GHC.IOBase Foreign.Marshal.Alloc
 Foreign.C.Types Foreign.Storable Foreign.Ptr Data.Maybe
  Foreign.Marshal.Alloc
imports: GHC.Num GHC.Base GHC.Err GHC.Ptr GHC.Real GHC.IOBase
 Foreign.ForeignPtr Foreign.Storable Foreign.C.Types  
Foreign.Ptr

 Data.Maybe
  Foreign.ForeignPtr
imports: GHC.ForeignPtr GHC.Err GHC.Num GHC.IOBase GHC.Base
 Foreign.Storable Foreign.Ptr
>

gmake[1]: *** [depend] Error 1
gmake: *** [boot] Error 1
gmake: Leaving directory `/tmp/ghc-6.4.2/libraries'


GHC.ForeignPtr does seem to be the root of much evil, since everything
seems to depend on it.  Any other hints on how I could get some output?

BTW, I have done some more tracing with gdb and I think I am a bit  
closer
to the underlying bug.  Before the bad call to newPinnedByteArray#,  
there
are a number of calls to functions bound to libc's regex functions  
(e.g., regcomp,
regexec). Since this is FreeBSD's libc, there may easily be  
differences from the much
better tested glibc.  It looks like the regex functions are being  
used to look
up package names, since I thought I saw a call from somewhere in  
Cabal.Distribution.

I need to check this once I get ghc-6.4.2 rebuilt.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: More on FreeBSD/amd64

[Gregory Wright]

Hi Ian,

On Apr 1, 2007, at 6:22 PM, Ian Lynagh wrote:


On Sun, Apr 01, 2007 at 06:10:25PM -0400, Gregory Wright wrote:


Ah, remove the #if/#endif around the definition of "puts", its  
export,

and the GHC.Pack import in libraries/base/GHC/Handle.hs


No such luck.  I even copied "puts" into libraries/base/GHC/
ForeignPtr.hs
but I still get I cycle because I need withCString to define "puts":


Oh, the 6.4.2 definition is different to the 6.6 definition.

Does the 6.6 one work with 6.4.2?:

puts :: String -> IO ()
puts s = do write_rawBuffer 1 (unsafeCoerce# (packCString# s))
0 (fromIntegral (length s))
return ()

(packCString# come from GHC.Pack)




Still doesn't work.  If I include the definition of write_rawBuffer just
above puts (I can't import GHC.Handle because of the dependency loop)
and dangerously change CInt to Int in the signature (can't import
Foreign.C.Types for the same reason) I still get an error message
saying that "fromInteger" is out of scope.

This is what I have added to libraries/base/GHC/ForeignPtr.hs:

import GHC.List ( null )
import GHC.Base
import GHC.IOBase
import GHC.List ( length )
import GHC.Pack -- this is new
import GHC.Ptr  ( Ptr(..) )
import GHC.Err
import GHC.Show

foreign import ccall unsafe "__hscore_PrelHandle_write"
   write_rawBuffer :: Int -> RawBuffer -> Int -> Int -> IO Int

puts :: String -> IO ()
puts s = do
write_rawBuffer 1 (unsafeCoerce# (packCString# s))
0 (length s)
return ()


I'm wondering if I should just give up on trying to print anything
out from this deep in the libraries and go back to looking at the
debugger trace.  My guess is still that a FreeBSD libc function
is getting called and somehow storing a 32 bit value in a 64 bit
location, with junk in the high order word.

As always, hints and firm whacks on the side of the head will be
appreciated.

Best Wishes,
Greg



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc development version (6.7) from MacPorts

[Gregory Wright]

Hi,

For those who live on the bleeding edge, I have made a port of the
latest development version of ghc for OS X through MacPorts.  (If you  
are not familiar

with MacPorts, see http://macports.org.)

The build is from the darcs repository, and installs its binaries
as -6.7. .  This naming allows the development
version to be installed alongside the released ghc-6.6 with no  
conflicts.


The port should work with OS X 10.3 and later on Intel or PPC.

The name of the port is "ghc-devel".

Note that because this is really a _development_ version, it may be
buggy or not build at all.  For day to day use you want the released
ghc-6.6.

Have fun,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

FreeBSD/amd64 registerised running

[Gregory Wright]

Hi Ian, Simon,

I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64.  The FreeBSD version is 6.2.

The problem with the compiler crash turned out to be simple.  In the
FreeBSD header file regex.h, regex_t is defined as

typedef struct {
int re_magic;
size_t re_nsub; /* number of parenthesized  
subexpressions */

__const char *re_endp;  /* end pointer for REG_PEND */
struct re_guts *re_g;   /* none of your business :-) */
} regex_t;

The problem is that the "re_magic" field is defined as an int.  When  
building
the .hc files on the i386 host, the re_nsub field is at an offset of  
4.  On the
amd64 target, it is at an offset of 8.  In the ghc binding to the  
regex functions,

re_nsub is used to compute how much memory to allocate in a call to
allocaBytes.  This leads to garbage being passed to newPinnedByteArray#.

The fix is to patch libraries/base/Text/Regex/Posix.hs on the amd64  
target:


--- libraries/base/Text/Regex/Posix.hs.sav  Thu Apr  5 12:05:22 2007
+++ libraries/base/Text/Regex/Posix.hs  Thu Apr  5 12:05:45 2007
@@ -106,7 +106,7 @@
regexec (Regex regex_fptr) str = do
   withCString str $ \cstr -> do
 withForeignPtr regex_fptr $ \regex_ptr -> do
-  nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) regex_ptr
+  nsub <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) regex_ptr
{-# LINE 109 "Posix.hsc" #-}
   let nsub_int = fromIntegral (nsub :: CSize)
   allocaBytes ((1 + nsub_int) * (16)) $ \p_match -> do

With this patch, we are pretty close.  However, there still seems to be
something wrong with the splitter.  I can make a working registerized
compiler if I set splitObjs=NO in build.mk, but it seems as if  
whatever is

wrong with ghc-split shouldn't be too hard to fix.

The splitting problem shows up as a linking failure.  Some variables
defined in the text section are changed from global symbols to local
symbols by the splitter.  An example (just one of several hundred
symbols that are changed from global to local):

From building ghc-6.6-20070405 on i386:

> nm --defined-only libHSbase.a | grep "D "


 D base_TextziReadziLex_zdLr3bklvl122_closure

and from building ghc-6.6-20070405 on amd64:

> nm --defined-only libHSbase.a | grep "d "


 d base_TextziReadziLex_zdLr3bklvl122_closure


The "D" on i386 indicates a global symbol, the "d" on amd64
a local symbol.

I've glanced at ghc-split.lprl, but on what files is it invoked? Can
I run it from the command line on a file and see check what comes out?
The file itself doesn't say what it expects as input, and the section
of the Commentary on the splitter is more than terse.

The linker is still broken (so no ghci):

greenhouse-george> ghci
   ___ ___ _
  / _ \ /\  /\/ __(_)
/ /_\// /_/ / /  | |  GHC Interactive, version 6.6.20770405, for  
Haskell 98.

/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

ghc-6.6.20770405: internal error: R_X86_64_PC32 relocation out of  
range: __isthreaded = 0xfff800122aad

(GHC version 6.6.20070405 for x86_64_unknown_freebsd)
Please report this as a GHC bug:  http://www.haskell.org/ghc/ 
reportabug

Abort trap: 6 (core dumped)

but I think I understand this.  On FreeBSD mmap does not have the
MAP_32BIT option that linux does to guarantee a mapping in first
2 GB of address space.  But by supplying a hint address in the lower
address space we can get the effect the MAP_32BIT option.  I thought I
had this fixed in the patch I applied to Linker.c, but I have  
obviously overlooked

something.

I'm continuing to work on the linker, and expect that it will be working
soon.  I'd appreciate a some guidance on the splitter question as I am
entirely unfamiliar with it.

Best Wishes,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FreeBSD/amd64 registerised running

[Gregory Wright]

Hi Ian,

On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:


On Sun, Apr 08, 2007 at 07:49:24PM -0400, Gregory Wright wrote:


I have ghc-6.6 (darcs version from 20070405) running registerized on
FreeBSD/amd64.


Excellent! Well done, and thanks for persevering!

It would be great if you could let us have a bindist and any necessary
patches.



I will certainly provide patches and a binary distribution that
people can use to bootstrap their own compilers.

I will try to get ghci running before I put out a release.


If you compile a module with

ghc -v -keep-tmp-files

then you should see the commandline it is using, and it should  
leave the

files for you to examine, and rerun the commands on, afterwards.


I'm giving this a try right now.

Best Wishes,
Greg



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FreeBSD/amd64 registerised running

[Gregory Wright]

Hi Ian,

On Apr 9, 2007, at 12:21 PM, Ian Lynagh wrote:


With this patch, we are pretty close.  However, there still seems  
to be

something wrong with the splitter.  I can make a working registerized
compiler if I set splitObjs=NO in build.mk, but it seems as if
whatever is
wrong with ghc-split shouldn't be too hard to fix.

I've glanced at ghc-split.lprl, but on what files is it invoked? Can
I run it from the command line on a file and see check what comes  
out?


If you compile a module with

ghc -v -keep-tmp-files

then you should see the commandline it is using, and it should  
leave the

files for you to examine, and rerun the commands on, afterwards.



I did this and immediately discovered that the problem is not with  
ghc-split
but with ghc-asm.  ".globl" directives are being deleted when they  
shouldn't be.


This is somewhat reminiscent of bug #1167, except that it seems to  
happen

far more frequently on amd64.  Perhaps someone has an idea of the top
of their head for this one.  I wouldn't be surprised if the fix for  
this also

took care of the bug on the less loved linux-ppc platform.

Best Wishes.
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FreeBSD/amd64 registerised running

[Gregory Wright]

Hi Olli,

On Apr 10, 2007, at 1:23 PM, Oliver Braun wrote:


Hi Gregory,

* Gregory Wright <[EMAIL PROTECTED]> [2007-04-09 12:38 -0400]:
I have ghc-6.6 (darcs version from 20070405) running  
registerized on

FreeBSD/amd64.



I will certainly provide patches and a binary distribution that
people can use to bootstrap their own compilers.


It would be nice if you cann provide a bootstrap tarball for  
integration

in the FreeBSD lang/ghc port.



I will do this as soon as I get the Linker bugs worked out so we can  
have ghci.
Since this won't make it into 6.6.1 a few patches will have to be  
applied

to the distribution.

Best Wishes,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: FreeBSD/amd64 registerised running

[Gregory Wright]

Just a further note on the FreeBSD/amd64 port.  I have the
mangler fixed up now, so the only remaining issue is the linker.

I hope to send patches soon.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildng ghc-devel from macports

[Gregory Wright]

Hi Chris,

On Apr 12, 2007, at 9:48 AM, C.M.Brown wrote:


Hello,

I've been trying to build the ghc-devel package (6.7) from macports.
However the build seems to fail half through. Specifically when  
running

the setup for base-2.1:

configure: Using compiler: ../../compiler/ghc-inplace
configure: Compiler flavor: GHC
configure: Compiler version: 6.7.20070411
configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace
configure: Using ar found on system at: /usr/bin/ar
configure: Using haddock found on system at: /opt/local/bin/haddock
configure: Using ld given by user at: /usr/bin/ld
configure: No pfesetup found
configure: Using ranlib found on system at: /usr/bin/ranlib
configure: Using runghc found on system at: /opt/local/bin/runghc
configure: No runhugs found
configure: Using tar found on system at: /usr/bin/tar
configure: Using happy: /opt/local/bin/happy
configure: Using alex: /opt/local/bin/alex
configure: Using hsc2hs: ../../utils/hsc2hs/hsc2hs-inplace
configure: No c2hs found
configure: No cpphs found
configure: No greencard found
Setup: Unrecognised flags:
 --with-cc=gcc
make[1]: *** [stamp/configure.library.build-profiling.base] Error 1
make: *** [stage1] Error 2

Hope someone can help!
kind regards,
Chris.


To tell what's going on I'll need the build.log output of

> sudo port -dv build ghc-devel > build.log 2>&1

This will be quite long, and you might want to compress it.  You can  
send
it to me directly (I maintain the macports ghc-devel port) if you'd  
like.


Please remember to run

> sudo port clean ghc-devel

first to clean out any previous stuff.  Macports can not yet properly
restart an interrupted build.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildng ghc-devel from macports

[Gregory Wright]

Hi Ian,

On Apr 13, 2007, at 9:19 AM, Ian Lynagh wrote:


On Thu, Apr 12, 2007 at 11:07:03AM -0400, Gregory Wright wrote:



configure: No cpphs found
configure: No greencard found
Setup: Unrecognised flags:
--with-cc=gcc
make[1]: *** [stamp/configure.library.build-profiling.base] Error 1
make: *** [stage1] Error 2


it to me directly (I maintain the macports ghc-devel port) if you'd
like.


It sounds like the port needs to be updated to run "sh boot"  
instead of

"autoreconf".


I can do this, but the previous procedure worked until a couple of weeks
ago.  Has something changed?

Greg

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Buildng ghc-devel from macports

[Gregory Wright]

Hi Ian,

On Apr 13, 2007, at 11:56 AM, Ian Lynagh wrote:


On Fri, Apr 13, 2007 at 10:27:54AM -0400, Gregory Wright wrote:


I can do this, but the previous procedure worked until a couple of  
weeks

ago.  Has something changed?


Yes; autoreconf and configure no longer recurse into the libraries (as
cabal was running configure too, so it was being run twice
unnecessarily).



The ghc-devel port in macports now uses the "boot" script instead
of autoreconf.  This fixes the reported problem.  It seems as if
someone has some work in progress that breaks the build, but
that's the risk when building from HEAD.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-6.6.1 for FreeBSD/amd64 binary distribution

[Gregory Wright]

Hi,

I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at

http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- 
freebsd.tar.bz2


No documentation or ghci.  The former might be easily remedied although
using FreeBSD's docbook chain, as suggested in the wiki, fails when  
asked
to generate printable docs. The latter seems to be a bigger project  
since my
naive interpretation of the problem is that we need data relocations  
across

a 2GB boundary.

The binary works well enough to build itself and darcs.  There are  
only sixteen
unexpected test suite failures thus far.  I am ignoring these for the  
moment while

I get back to thinking about ghci.

Note that you need to install libgmp to use the compiler.  libgmp  
from the

ports collection works fine.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-6.6.1 for FreeBSD/amd64 binary distribution

[Gregory Wright]

Hi Simon,

On May 30, 2007, at 4:05 PM, Simon Marlow wrote:


Gregory Wright wrote:


I have put a binary distribution of ghc-6.6.1 for FreeBSD/amd64
at
http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-x86_64-unknown- 
freebsd.tar.bz2


yay!  Ian will supply a link from the download page in due course,  
I'm sure.





I still owe you some source patches to make the compiler build out of  
the
box.  If 6.6.1 is the end of the line, would you prefer that these be  
against HEAD?
Should I ask for push permission or just send these via the usual  
darcs send

route (now possible, since darcs builds on x86_64)?

The x86-64 (or amd64 if you like) Linux port doesn't do relocation  
of data references outside 2Gb.  It is the subject of this bug:


  http://hackage.haskell.org/trac/ghc/ticket/781

the underlying problem is that the relocatable reference is only 32  
bits, because we're working in the small memory model, but the  
address of the symbol might be outside the current 2Gb slice,  
because it's in a shared library somewhere.  The system linker  
solves this by relocating the data itself from the shared library  
into the main program's 2Gb slice (I think), but we can't do this  
in GHCi.




Hmm.  I would have thought that the absolute addresses of static data  
in the shared library would have been
resolved by the run time loader and written into the global offset  
table.  It seems that all of the
shared libraries on FreeBSD/amd64 are loaded at addresses above 2 GB,  
e.g., above 0x8.
Perhaps rtld allocates space below 2GB and fills in adjusts the GOT  
to point to the data in lower memory.

(There's not very much of it).  I'll have to think about this a while.

Fortunately most code doesn't reference static data from shared  
libraries, so we get away with it most of the time.




FreeBSD/amd64 seems to make a lot of references to static data.  When  
I edited the Linker
to ignore out of range relocations and print a message I got dozens  
while starting GHCi.


Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Failure building HEAD

[Gregory Wright]

Hi,

Today I was building HEAD using macports and had the error:

configure: Using compiler: ../../compiler/ghc-inplace
configure: Compiler flavor: GHC
configure: Compiler version: 6.7.20070607
configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace
checking for gcc... gcc
checking for C compiler default output file name... configure: error:  
C compiler cannot create executables

See `config.log' for more details.

(this was in libraries/base).  The config.log showed the problem:

configure:1680: checking for C compiler default output file name
configure:1683: gcc -I/opt/local/include --configure-option=-O2 -I/ 
opt/local/include --configure-option=-I/opt/local/include -L/opt/ 
local/lib --configure-option=-L/opt/local/lib conftest.c  >&5

cc1: error: unrecognized command line option "-fconfigure-option=-O2"
cc1: error: unrecognized command line option "-fconfigure-option=-I/ 
opt/local/include"cc1: error: unrecognized command line option "- 
fconfigure-option=-L/opt/local/lib"configure:1686: $? = 1



It looks like cabal is messed up, passing "--configure-option=" when  
it should be

stripping it out.

Is this a problem with the HEAD branch or do I need a development  
version

of cabal from the darcs repository to build the latest ghc?

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Failure building HEAD

[Gregory Wright]

Hi Ian,

On Jun 8, 2007, at 11:24 AM, Ian Lynagh wrote:


On Thu, Jun 07, 2007 at 11:56:35AM -0400, Gregory Wright wrote:


Is this a problem with the HEAD branch or do I need a development
version
of cabal from the darcs repository to build the latest ghc?


I'm not sure exactly what you mean. You need the latest darcs Cabal in
libraries/Cabal in your GHC tree, and if this is a tree that you have
previously built then you may also need to first remove
libraries/stamp/bootstrapping.Cabal. However, you don't need the  
latest

Cabal registered with the GHC that you are building /with/.



I started by deleting my old directory and doing a fresh get from the  
darcs
repository so there was nothing left over from a previous build.  It  
looks as
if something is broken then.  For example, "--configure-option=-O2"  
is showing up in the
command line of gcc when one of the test programs is built by the  
configure
script in libraries/base. I assume that this should just have been "- 
O2".

The configure script fails because gcc barfs on the unrecognized option.

So no new dependencies have been introduced in the HEAD build as I
understand it.  Anyone else have problems building HEAD in the last  
couple
of days.  I know it's not just me; it was reported to me by another  
person

using macports to build HEAD.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Failure building HEAD

[Gregory Wright]

Hi Ian,

On Jun 8, 2007, at 12:03 PM, Ian Lynagh wrote:



Hmm, what is the complete command (i.e. with all arguments) that  
starts

"cd base && setup/Setup configure"?




make -C libraries all
rm -f -f stamp/configure.library.*.base base/unbuildable
( cd base && setup/Setup configure \
--enable-library-profiling --enable-split-objs \
   --prefix=/opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ 
destroot//opt/local \

   --with-compiler=../../compiler/ghc-inplace \
   --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \
   --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \
   --with-ld=/usr/bin/ld \
   --datasubdir=ghc \
   --haddock-args="--use-contents=../index.html \
   --use-index=../doc-index.html" \
   --configure-option='--prefix=/opt/local' --configure- 
option='--prefix=/opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ 
destroot//opt/local' --configure-option='--mandir=/opt/local/var/db/ 
dports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/ 
work/destroot//opt/local/share/man/' --configure-option='--with- 
readline-includes=/opt/local/include' --configure-option='--with- 
readline-libraries=/opt/local/lib' --configure-option='--with-gmp- 
includes=/opt/local/include' --configure-option='--with-gmp- 
libraries=/opt/local/lib' --configure-option='--disable-openal' -- 
configure-option='--disable-alut' --configure-option='CFLAGS=-I/opt/ 
local/include --configure-option=-O2' --configure-option='CPPFLAGS=-I/ 
opt/local/include --configure-option=-I/opt/local/include' -- 
configure-option='LDFLAGS=-L/opt/local/lib --configure-option=-L/opt/ 
local/lib' \

   --configure-option=--with-cc=gcc ) \
  && touch stamp/configure.library.build-profiling- 
splitting.base || touch base/unbuildable

Setup: Warning: Unknown field 'nhc98-options'
configure: Reading installed packages...
Configuring base-2.1...
configure: Using install prefix: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local
configure: Binaries installed in: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local/bin
configure: Libraries installed in: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local/lib/base-2.1/ghc-6.7.20070608
configure: Private binaries installed in: /opt/local/var/db/dports/ 
build/_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ 
destroot/opt/local/libexec
configure: Data files installed in: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local/share/ghc

configure: Using compiler: ../../compiler/ghc-inplace
configure: Compiler flavor: GHC
configure: Compiler version: 6.7.20070608
configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace
configure: Using ar found on system at: /usr/bin/ar
configure: Using haddock found on system at: /opt/local/bin/haddock
configure: Using ld given by user at: /usr/bin/ld
configure: No pfesetup found
configure: Using ranlib found on system at: /usr/bin/ranlib
configure: Using runghc found on system at: /opt/local/bin/runghc
configure: Using runhugs found on system at: /opt/local/bin/runhugs
configure: Using tar found on system at: /usr/bin/tar
configure: Using happy: /opt/local/bin/happy
configure: Using alex: /opt/local/bin/alex
configure: Using hsc2hs: ../../utils/hsc2hs/hsc2hs-inplace
configure: Using c2hs: /opt/local/bin/c2hs
configure: Using cpphs: /opt/local/bin/cpphs
configure: No greencard found
configure: Reading installed packages...
Configuring base-2.1...
configure: Dependency rts-any: using rts-1.0
configure: Using install prefix: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local
configure: Binaries installed in: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local/bin
configure: Libraries installed in: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local/lib/base-2.1/ghc-6.7.20070608
configure: Private binaries installed in: /opt/local/var/db/dports/ 
build/_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/ 
destroot/opt/local/libexec
configure: Data files installed in: /opt/local/var/db/dports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc-devel/work/destroot/ 
opt/local/share/ghc

configure: Using compiler: ../../compiler/ghc-inplace
configure: Compiler flavor: GHC
configure: Compiler version: 6.7.20070608
configure: Using package tool: ../../utils/ghc-pkg/ghc-pkg-inplace
checking for gcc... gcc
checking for C compiler default output file name... configure: error:  
C compiler cannot cre

Re: 6.6.1 + DoCon on Mac OS

[Gregory Wright]

Hi Serge,

On Sep 4, 2007, at 4:27 AM, Serge D. Mechveliani wrote:


People,

please, who can advise about  ghc-6.6.1 + DoCon  on Mac OS ?

in DoCon-2.09 and tell whether this installation is likely to work
under  Mac OS ?
How  DoCon-2.09 + ghc-6.6.1  can be ported to  Mac OS ?




I ported DoCon 2.09 to OS X using the MacPorts infrastructure several  
months ago.
It built fine, and I was able to run a few simple tests.  I didn't  
check it in for some
reason --- I probably just forgot.  I have fixed that.  DoCon is now  
available from MacPorts.


The build depends on having ghc from MacPorts.  If ghc is not  
installed, it will be built

from source.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Which ghc versions can build ghc-6.8.1?

[Gregory Wright]

Hi,

I'm the process of updating MacPort's ghc to 6.8.1 and adding support  
for

Leopard (OS X 10.5) and have been having] some trouble.

The first task is just to get 6.8.1 running on Tiger (10.4).  On PPC,  
I use
ghc 6.4 as a bootstrap compiler and on Intel ghc 6.6.  I am traveling  
with

only a PPC PowerBook G4/OS X 10.4, so that's all I've been able to
test with.

The problem is that ghc 6.4 can not build 6.8.1.  It seems related to  
Cabal.
Using the 6.4 bootstrap compiler (with the version of Cabal that it  
shipped

with) I get:

ranlib libHSrts_thr_debug.a

== Finished recursively making `all' for ways: p  debug  thr thr_p  
thr_debug ...
PWD = /opt/local/var/macports/build/_Users_gwright_src_macports- 
trunk_dports_lang_ghc/work/ghc-6.8.1/rts


make -C libraries boot
rm -f -rf bootstrapping.Cabal
cp -R Cabal bootstrapping.Cabal
/usr/bin/find bootstrapping.Cabal \( -name "*.o" -o -name "*.hi" \) \
 -exec rm -f -f {} \;
touch stamp/bootstrapping.Cabal
rm -f -rf bootstrapping.filepath
cp -R filepath bootstrapping.filepath
/usr/bin/find bootstrapping.filepath \( -name "*.o" -o -name "*.hi" \) \
 -exec rm -f -f {} \;
touch stamp/bootstrapping.filepath
rm -f -rf ifBuildable
mkdir ifBuildable
cp ifBuildable.hs ifBuildable/
cd ifBuildable && /opt/local/var/macports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc/work/ghc-bootstrap/ 
bin/ghc -Wall --make ifBuildable -o ifBuildable

Chasing modules from: ifBuildable
Compiling Main ( ifBuildable.hs, ifBuildable.o )
Linking ...
ld: warning prebinding disabled because dependent library: /opt/local/ 
lib/libgmp.3.dylib is not prebound

rm -f -rf base/setup
mkdir base/setup
cp base/Setup.*hs base/setup
cd base/setup && /opt/local/var/macports/build/ 
_Users_gwright_src_macports-trunk_dports_lang_ghc/work/ghc-bootstrap/ 
bin/ghc -Wall -cpp --make Setup.*hs -o Setup \
  -DCABAL_VERSION=1,2,2,0 -i../../ 
bootstrapping.Cabal -i../../bootstrapping.filepath

Chasing modules from: Setup.hs
Compiling System.FilePath.Posix ( ../../bootstrapping.filepath/System/ 
FilePath/Posix.hs, ../../bootstrapping.filepath/System/FilePath/ 
Posix.o )
Compiling System.FilePath  ( ../../bootstrapping.filepath/System/ 
FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o )

Compiling Main ( Setup.hs, Setup.o )

Setup.hs:19:18: Not in scope: `buildHook'

Setup.hs:21:30: Not in scope: `buildHook'

Setup.hs:22:18: Not in scope: `makefileHook'

Setup.hs:24:33: Not in scope: `makefileHook'

Setup.hs:25:18: Not in scope: `instHook'

Setup.hs:26:29: Not in scope: `instHook'

Setup.hs:33:12: Not in scope: `compilerFlavor'

Setup.hs:33:45: Not in scope: data constructor `GHC'
make[1]: *** [base/setup/Setup] Error 1
make: *** [stage1] Error 2


If I upgrade the bootstrap compiler's Cabal to 1.1.6.2, the build  
still fails.

(The old version of Cabal was unregistered according the instructions
for working with older versions of ghc & Cabal.)

ranlib libHSrts_thr_debug.a

== Finished recursively making `all' for ways: p  debug  thr thr_p  
thr_debug ...

PWD = /Users/gwright/Desktop/ghc-6.8.1/rts

make -C libraries boot
rm -f -rf bootstrapping.Cabal
cp -R Cabal bootstrapping.Cabal
/usr/bin/find bootstrapping.Cabal \( -name "*.o" -o -name "*.hi" \) \
 -exec rm -f -f {} \;
touch stamp/bootstrapping.Cabal
rm -f -rf bootstrapping.filepath
cp -R filepath bootstrapping.filepath
/usr/bin/find bootstrapping.filepath \( -name "*.o" -o -name "*.hi" \) \
 -exec rm -f -f {} \;
touch stamp/bootstrapping.filepath
rm -f -rf ifBuildable
mkdir ifBuildable
cp ifBuildable.hs ifBuildable/
cd ifBuildable && /opt/local/bin/ghc -Wall --make ifBuildable -o  
ifBuildable

Chasing modules from: ifBuildable
Compiling Main ( ifBuildable.hs, ifBuildable.o )
Linking ...
rm -f -rf base/setup
mkdir base/setup
cp base/Setup.*hs base/setup
cd base/setup && /opt/local/bin/ghc -Wall -cpp --make Setup.*hs -o  
Setup \
  -DCABAL_VERSION=1,2,2,0 -i../../ 
bootstrapping.Cabal -i../../bootstrapping.filepath

Chasing modules from: Setup.hs
Compiling System.FilePath.Posix ( ../../bootstrapping.filepath/System/ 
FilePath/Posix.hs, ../../bootstrapping.filepath/System/FilePath/ 
Posix.o )
Compiling System.FilePath  ( ../../bootstrapping.filepath/System/ 
FilePath.hs, ../../bootstrapping.filepath/System/FilePath.o )

Compiling Main ( Setup.hs, Setup.o )

Setup.hs:22:18: Not in scope: `makefileHook'

Setup.hs:24:33: Not in scope: `makefileHook'
make[1]: *** [base/setup/Setup] Error 1
make: *** [stage1] Error 2


With my installed 6.6.1 (and the Cabal 1.1.6.2 sh

Re: GHC 6.8.1 on Mac OS 10.5 Leopard (Intel) - Configure fails

[Gregory Wright]

On Dec 10, 2007, at 3:21 PM, Carsten Keßler wrote:

Basically, I just wanted to get this thing running without too much  
hassle... Does anyone have an idea why the GHC distribution  
available via MacPorts does not work at the moment?





Hi Carsten,

The ghc distribution on MacPorts doesn't support 6.8.1 yet because I  
haven't finished porting it.


The whole 6.8.1 release is sort of a mess. Our old bootstrap compiler  
on ppc (version 6.4) seems
not to be able to build 6.8.1, contrary to expectations.  I can get  
6.6.1 to build 6.8.1, so I may just
have to update the bootstrap compiler.  (Updating the bootstrap  
compiler is a fair amount of work,
mostly to check that no unnecessary dependencies get included.  This  
is essential so that the

process "just works" for most people.)

I had asked on this list several days ago if anyone knew what  
versions of ghc were capable
of building 6.8.1 and received no answer to this question.  AFAIK,  
only 6.6.1 is capable of building
6.8.1, despite the the website's advertising that any version > 6.0  
should be sufficient.

(The libraries for 6.8.1 seem to need 6.2 or later.)

This will all take some time to sort out but it is being worked on.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 6.8.1 on Mac OS 10.5 Leopard (Intel) - Configure fails

[Gregory Wright]

On Dec 11, 2007, at 3:23 AM, Carsten Keßler wrote:


Hi,

so does the GMP.framework installed via MacPorts do it, or not?!  
Apparently, it doesn't:



-snip

Macintosh-4:~ Carsten$ port installed
The following ports are currently installed:
...
  gmp @4.2.2_0 (active)
  readline @5.2.007_0+darwin_9 (active)



Hi Carsten,

MacPorts does not install gmp as a framework (that is, native OS X  
style).
Instead it installs it as a unix style library, usually in /opt/local/ 
lib.


MacPorts patches the configure.ac file to remove the test for the gmp
framework.  You can do this by hand, then run "autoreconf".  Then
specify --with-gmp-includes= and --with-gmp- 
libraries=

to configure to ensure the installed gmp is found.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Which ghc versions can build ghc-6.8.1?

[Gregory Wright]

Hi Simon,
On Dec 11, 2007, at 6:13 AM, Simon Marlow wrote:


Gregory Wright wrote:


Can 6.4 build 6.8.1?  Or is a later version required?


We test the GHC build with 6.2.2, and the latest released version  
(previously 6.6.1, now 6.8.1).  It's not unlikely that bugs have  
crept in that make the build fail with 6.4.x; if you find any such  
bugs then please do let us have a fix.




Thank you, that is helpful to know.  I've found a few trivial buglets  
and maybe one less
trivial.  I'll send patches when I get the build to go all the way  
through.


Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2

[Gregory Wright]

Hi,

On Dec 20, 2007, at 2:31 PM, Hugo Pacheco wrote:

>From the ghc-6.8.2 sources then, I'm just afraid of possible  
errors, and I don't have any previous ghc installed.


Do the sources permit bootstrapping? From what I know...
The source distribution needs an installed GHC (version 6.0 at  
least). If your platform isn't currently supported with a binary  
distribution, then you'll need to consult the section on Porting GHC  
in the Building Guide.


I'm afraid of the same error as macports 6.6.1:

configure: error: GHC is required unless bootstrapping from .hc files.



The macports 6.8.2 should be ready soon for Tiger (PPC and Intel) and  
Leopard (Intel only).
I have had successful builds on these platforms and the Portfile is  
updated.  However,
the 6.8 branch seems to have introduced a bug in file locking (#1992  
in the trac) that
causes the build to fail once out of every four or five times.  This  
is not acceptable for
a production release, so this has to be tracked down before GHC from  
macports is

updated.

Sorry for the delay,
Greg



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2

[Gregory Wright]

On Dec 20, 2007, at 5:30 PM, Hugo Pacheco wrote:


But is it like days, weeks, months?
I really need GHC installed on my intel mac w/ leopard.



The new macports ghc should be ready in days to a week, most likely.   
If you want I can send you
the portfile to try, I can't guarantee it but it seems to work most of  
the time.  If the build fails,

just "sudo port clean" and try again.


How can I build the libraries in the current leopard release?


I don't understand your question.  Which libraries do you want to build?

-Greg


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.8.2

[Gregory Wright]

Hi Christophe,

On Dec 23, 2007, at 11:02 AM, alpheccar wrote:


Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ?
I had no problems to build the 6.8.1 but with 6.8.2, I get the error:

I was able to build 6.8.2 three times on PPC/Tiger (10.4.11) without  
error
using 6.6.1 as a boostrap compiler.  What are you using to compile  
6.8.2?


../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide- 
all-packages -split-objs -i -idist/build/autogen -idist/build -i. - 
Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir  
dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts - 
package-name base -XCPP -idist/build  -H16m -O -O -Rghc-timing - 
fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/ 
Twins.o  -ohi dist/build/Data/Generics/Twins.hi

ghc-6.8.2: panic! (the 'impossible' happened)
 (GHC version 6.8.2 for powerpc-apple-darwin):
   lookupVers1 base:GHC.Prim sym{tc}

Please report this as a GHC bug:  http://www.haskell.org/ghc/ 
reportabug




Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: patch applied (cabal): make rawSystemStdout put its temp files in the temp dir rather than cwd

[Gregory Wright]

Hi Duncan,

(Cross-posting to ghc-users since some of the issues were brought up  
there.)


On Dec 2, 2007, at 5:04 PM, Duncan Coutts wrote:


Sun Dec  2 14:06:20 PST 2007  Duncan Coutts <[EMAIL PROTECTED]>
 * make rawSystemStdout put its temp files in the temp dir rather  
than cwd

 Should fixe reported wierdness with finding program version numbers

   M ./Distribution/Simple/Utils.hs -2 +4



I saw this problem when trying to build 6.8.1 on a mac (Leopard/Intel)  
using
6.4 to build compiler.  I edited rawSystemStdout to put the tmp files  
directory
in "/tmp" instead of using getTemporaryDirectory.  On this combination  
of compilers,
moving the temporary file did not fix the problem of finding the  
program version
number.  The underlying error was that the temp file was reported to  
still

be locked.

Building 6.8.2 with another 6.8.2 eliminated the program version  
problem,
but I have seen two other intermittent errors which seem to be  
related.  (Reported
in trac as issue #1992.)  Building 6.8.2 with 6.8.2 using the MacPorts  
infrastructure,

I get this error about half the time:

	../compiler/stage1/ghc-inplace -M -optdep-f -optdep.depend-BASE  - 
osuf o -I../includes   -H16m -O -I/opt/local/include -I/usr/include -L/ 
opt/local/lib -L/usr/lib -iutils -ibasicTypes -itypes -ihsSyn - 
iprelude -irename -itypecheck -ideSugar -icoreSyn -ivectorise - 
ispecialise -isimplCore -istranal -istgSyn -isimplStg -icodeGen -imain  
-iprofiling -iparser -icprAnalysis -indpFlatten -iiface -icmm - 
inativeGen -ighci -Wall -fno-warn-name-shadowing -fno-warn-orphans - 
Istage2 -package hpc -package bytestring -DGHCI -package template- 
haskell -DGHCI_TABLES_NEXT_TO_CODE -package readline -DUSE_READLINE - 
cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package  
unix -package Cabal -ignore-package lang -recomp -Rghc-timing -H16M '- 
#include "cutils.h"' -package-name ghc-6.8.2 -fgenerics basicTypes/ 
BasicTypes.lhs basicTypes/DataCon.lhs basicTypes/Demand.lhs basicTypes/ 
Id.lhs basicTypes/IdInfo.lhs basicTypes/Literal.lhs basicTypes/ 
MkId.lhs basicTypes/Module.lhs basicTypes/Name.lhs basicTypes/ 
NameEnv.lhs basicTypes/NameSet.lhs basicTypes/NewDemand.lhs basicTypes/ 
OccName.lhs basicTypes/RdrName.lhs basicTypes/SrcLoc.lhs basicTypes/ 
UniqSupply.lhs basicTypes/Unique.lhs basicTypes/Var.lhs basicTypes/ 
VarEnv.lhs basicTypes/VarSet.lhs cmm/CLabel.hs cmm/Cmm.hs cmm/ 
CmmBrokenBlock.hs cmm/CmmCPS.hs cmm/CmmCPSGen.hs cmm/CmmCallConv.hs  
cmm/CmmInfo.hs cmm/CmmLex.hs cmm/CmmLint.hs cmm/CmmLive.hs cmm/ 
CmmOpt.hs cmm/CmmParse.hs cmm/CmmProcPoint.hs cmm/CmmUtils.hs cmm/ 
Dataflow.hs cmm/MachOp.hs cmm/PprC.hs cmm/PprCmm.hs codeGen/Bitmap.hs  
codeGen/CgBindery.lhs codeGen/CgCallConv.hs codeGen/CgCase.lhs codeGen/ 
CgClosure.lhs codeGen/CgCon.lhs codeGen/CgExpr.lhs codeGen/ 
CgForeignCall.hs codeGen/CgHeapery.lhs codeGen/CgHpc.hs codeGen/ 
CgInfoTbls.hs codeGen/CgLetNoEscape.lhs codeGen/CgMonad.lhs codeGen/ 
CgParallel.hs codeGen/CgPrimOp.hs codeGen/CgProf.hs codeGen/ 
CgStackery.lhs codeGen/CgTailCall.lhs codeGen/CgTicky.hs codeGen/ 
CgUtils.hs codeGen/ClosureInfo.lhs codeGen/CodeGen.lhs codeGen/ 
SMRep.lhs coreSyn/CoreFVs.lhs coreSyn/CoreLint.lhs coreSyn/ 
CorePrep.lhs coreSyn/CoreSubst.lhs coreSyn/CoreSyn.lhs coreSyn/ 
CoreTidy.lhs coreSyn/CoreUnfold.lhs coreSyn/CoreUtils.lhs coreSyn/ 
ExternalCore.lhs coreSyn/MkExternalCore.lhs coreSyn/PprCore.lhs  
coreSyn/PprExternalCore.lhs cprAnalysis/CprAnalyse.lhs deSugar/ 
Check.lhs deSugar/Coverage.lhs deSugar/Desugar.lhs deSugar/ 
DsArrows.lhs deSugar/DsBinds.lhs deSugar/DsCCall.lhs deSugar/ 
DsExpr.lhs deSugar/DsForeign.lhs deSugar/DsGRHSs.lhs deSugar/ 
DsListComp.lhs deSugar/DsMeta.hs deSugar/DsMonad.lhs deSugar/ 
DsUtils.lhs deSugar/Match.lhs deSugar/MatchCon.lhs deSugar/ 
MatchLit.lhs ghci/ByteCodeAsm.lhs ghci/ByteCodeFFI.lhs ghci/ 
ByteCodeGen.lhs ghci/ByteCodeInstr.lhs ghci/ByteCodeItbls.lhs ghci/ 
ByteCodeLink.lhs ghci/Debugger.hs ghci/GhciMonad.hs ghci/GhciTags.hs  
ghci/InteractiveUI.hs ghci/Linker.lhs ghci/ObjLink.lhs ghci/ 
RtClosureInspect.hs hsSyn/Convert.lhs hsSyn/HsBinds.lhs hsSyn/ 
HsDecls.lhs hsSyn/HsDoc.hs hsSyn/HsExpr.lhs hsSyn/HsImpExp.lhs hsSyn/ 
HsLit.lhs hsSyn/HsPat.lhs hsSyn/HsSyn.lhs hsSyn/HsTypes.lhs hsSyn/ 
HsUtils.lhs iface/BinIface.hs iface/BuildTyCl.lhs iface/IfaceEnv.lhs  
iface/IfaceSyn.lhs iface/IfaceType.lhs iface/LoadIface.lhs iface/ 
MkIface.lhs iface/TcIface.lhs main/BreakArray.hs main/CmdLineParser.hs  
main/CodeOutput.lhs main/Config.hs main/Constants.lhs main/ 
DriverMkDepend.hs main/DriverPhases.hs main/DriverPipeline.hs main/ 
DynFlags.hs main/ErrUtils.lhs main/Finder.lhs main/GHC.hs main/ 
HeaderInfo.hs main/HscMain.lhs main/HscStats.lhs main/HscTypes.lhs  
main/InteractiveEval.hs main/Main.hs main/PackageConfig.hs main/ 
Packages.lhs main/ParsePkgConf.hs main/PprTyThing.hs main/ 
StaticFlags.hs main/SysTools.lhs main/TidyPgm.lhs nativeGen/ 
AsmCodeGen.lhs nativeGen/GraphBase.hs nativeGen/GraphColor.hs  
nativeGe

ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

After what many would consider an unconscionable delay, I am happy to  
announce

that ghc 6.8.2 is available from MacPorts.

The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ 
intel.  Users with
Leopard/ppc are out of luck until for now, for reason discussed  
earlier on this list.


In partial recompense for their patience, users will get a ghc with  
more patches

than any previous MacPorts ghc.

A few notes:

	The file locking bugs #1992 and #2134 are fixed.  Bug #1992 was a  
simple
	lock logic error and should be killed dead.  Bug #2134 was the result  
of a lazy readFile
	holding a lock for an unpredictable time.  There may be more cases  
like this one,
	and I would appreciate a note from anyone who come across a lock  
error during building.


	Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug  
which under
	unusual circumstances would repeatably (and mysteriously) crash the  
build.
	This was first noticed running the building in an eshell under  
Aquamacs.  Archives
	were built without tables of contents because ranlib wasn't being run  
or wasn't
	running to completion.  Builds in the usual Terminal.app didn't trip  
over this bug.


	OpenGL support is built by default.  It can be turned off using the  
no_opengl variant.


	OpenAL support is disabled.  Apple's OpenAL framework lacks ALUT  
support (needed
	for the ghc binding) but has name clashes with the freealut library  
from the OpenAL.org
	website.  Fixing this is probably straightforward.  If someone is  
interested, I can give

them some pointers on getting started.

	MacPort's ghc ought to always link with the correct libgmp (the one  
provided by the gmp port).



The latest versions of alex, happy, haddock and hs-Edison are also  
available.



Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

On Mar 5, 2008, at 4:21 AM, Jinwoo Lee wrote:


Thank you!
But "ghc" has disappeared from MacPorts SW list.
Only "ghc-devel" can be seen.
Please look into it.



ghc vanished from the distribution server for a few hours yesterday  
because of a
unanticipated corner case in the indexing script.  (The server runs  
Leopard/ppc,
and incorrectly rejected ports that correctly reported that they do  
not run on Leopard/ppc.)

A workaround was implemented and it is now available.

MacPorts helps debug ghc and ghc helps debug MacPorts!

-Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

Hi Wouter,

On Mar 6, 2008, at 12:57 PM, Wouter Swierstra wrote:


Hi Greg,

Thanks again for maintaining ghc in macports!

I tried installing ghc through macports. Unfortunately, the build  
failed with the following error message below. I'd be happy to send  
you a complete log, if you think it would help. Many thanks,


 Wouter



main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries'

main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries'

main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs'

main/ParsePkgConf.hs:299:35: Not in scope: `includes'

main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions'

main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions'

main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions'

main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs'

main/ParsePkgConf.hs:304:35: Not in scope: `frameworks'

main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces'

main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs'

main/ParsePkgConf.hs:307:34: Not in scope: `depends'

main/ParsePkgConf.hs:320:43: Not in scope: `depends'
>

make[2]: *** [stage2/main/ParsePkgConf.o] Error 1
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2

Warning: the following items did not execute (for ghc):  
org.macports.activate org.macports.build org.macports.destroot  
org.macports.install

Error: Status 1 encountered during processing.



This is odd.  What platform (intel/ppc and OS X version) are you  
running on?


A complete log would help too. The output of

# sudo port -dv destroot ghc > dest.log 2>&1

is good.  You will probably want to compress the log file before  
sending.


One thing you might try is to ensure that you have no failed build  
lying around

by running

# sudo port clean ghc
# sudo port install ghc

The combination of ghc Makefiles and MacPorts infrastructure is not  
able to recover
from a failed or interrupted build.  You need to clean up and start  
over.  You should

also clean before recording the log.

Best,
greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANN: prof2dot, a graphical profiling tool

[Gregory Wright]

I am pleased to announce the first release of prof2dot, a graphical  
profiling tool

for use with GHC.

While GHC has in the past worked with graphical profiling tools, they
have been heavyweight and/or proprietary.  Prof2dot is a simple tool for
converting profiling information into a graphical format, released  
under a BSD3
license.  It is simple because it offloads all of the work of  
rendering the graph
onto Graphviz.  So you need to install the Graphviz tools in order to  
use it.


The program is a filter that takes the profiling output generated by  
running

a GHC-compiled program with the "+RTS -px -RTS" option and turns it into
a dot file.  (The "dot" format is a textual representation of a  
directed or undirected graph.)

The dot file can rendered in any format supported by Graphviz's
dot program, and the file itself can be post-processed or edited to  
adjust the

layout.

Features of prof2dot:

* display either the call graph (default) or the call tree,

* colorize by cost center count, time or allocations,

* group cost centers in the same module.

Prof2dot installs as a typical caballized application.
Running "prof2dot -?" from the command line will give a short summary of
how to use the program and its options.

Rendering very large graphs can exceed the internal resource limits of  
dot.
You may have to compile your own version of the Graphviz tools with  
higher limits

to handle these cases.

A example of a colorized profile of a medium sized project is shown on  
our
company's web site: http://antiope.com/downloads.html.  Click on the  
small

image to download a pdf of the complete profile graph.

Prof2dot is available from hackage or the link given above.


-Greg___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

Hi Christian,

On Mar 13, 2008, at 7:10 AM, Christian Maeder wrote:


I was able to build ghc 6.8.2 on Leopard/ppc using the patch from

http://hackage.haskell.org/trac/ghc/ticket/1958
(also below)

Could you try if it works for you, too?


I forgot to mention, that I had to build a bootstrapping compiler on  
pcc

tiger with this patch first.



I'll build a bootstrap compiler with this patch today so we can give  
it a try. Thanks!


-Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc's trac is wedged

[Gregory Wright]

Hi,

This morning (13 March 2008) the ghc trac wedged reporting

Trac detected an internal error:

with the python traceback

Traceback (most recent call last):
  File "/var/lib/python-support/python2.4/trac/web/main.py", line  
387, in dispatch_request

dispatcher.dispatch(req)
  File "/var/lib/python-support/python2.4/trac/web/main.py", line  
237, in dispatch

resp = chosen_handler.process_request(req)
  File "/var/lib/python-support/python2.4/trac/web/auth.py", line  
100, in process_request

self._do_login(req)
  File "/var/lib/python-support/python2.4/trac/web/auth.py", line  
139, in _do_login

"VALUES (%s, %s, %s, %s)", (cookie, remote_user,
  File "/var/lib/python-support/python2.4/trac/db/util.py", line 50,  
in execute

return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 237,  
in execute

self.con._begin()
  File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 503,  
in _begin

self.db.execute("BEGIN")
OperationalError: database is locked


Please let me know if there is a more direct way to report failures  
such as this one,

instead of posting to the list.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Success report: Leopard powerpc

[Gregory Wright]

Excellent news.  Thanks to you and Christian for trying it out.

-Greg

On Mar 17, 2008, at 4:12 PM, Chris Kuklewicz wrote:

I used both ghc-6.6.1 and macports to create a working ghc-6.8.2 on  
OS X 10.5.2 on a powerpc G4 laptop.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: prof2dot, a graphical profiling tool

[Gregory Wright]

Hi Cristian,

On Apr 1, 2008, at 11:03 AM, Cristian Perfumo wrote:

I was wondering if it handles per-thread information when you have  
more than one thread involved. (Actually the question is not related  
to the graphical tool, but the announcement triggered it).


The prof2dot tool only knows about the information that is in the  
profiling dump file.  IIRC,
cost centers are not associated with threads in this file.  (The  
format isn't documented, but
it is not hard to figure out, given a look at the code that generates  
it.)


Is recording the thread in which a cost was incurred really helpful?   
If it is, I could look into
adding it.  But are you more interested in a graphical representation  
of thread execution ---
which threads are executing and when?  You should check if any of the  
old
Glasgow Parallel Haskell tools are close to what you want.  If so, it  
might be less

work to resurrect one of those.

Best Wishes,
Greg



Best.
Cristian

2008/3/8 Gregory Wright <[EMAIL PROTECTED]>:


I am pleased to announce the first release of prof2dot, a graphical  
profiling tool

for use with GHC.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

Hi Björn,

On Apr 24, 2008, at 6:41 AM, Bjorn Bringert wrote:

On Thu, Mar 6, 2008 at 7:57 PM, Wouter Swierstra <[EMAIL PROTECTED]>  
wrote:

Hi Greg,

Thanks again for maintaining ghc in macports!

I tried installing ghc through macports. Unfortunately, the build  
failed
with the following error message below. I'd be happy to send you a  
complete

log, if you think it would help. Many thanks,

Wouter



main/ParsePkgConf.hs:296:35: Not in scope: `extraLibraries'

main/ParsePkgConf.hs:297:35: Not in scope: `extraGHCiLibraries'

main/ParsePkgConf.hs:298:35: Not in scope: `includeDirs'

main/ParsePkgConf.hs:299:35: Not in scope: `includes'

main/ParsePkgConf.hs:300:35: Not in scope: `hugsOptions'

main/ParsePkgConf.hs:301:35: Not in scope: `ccOptions'

main/ParsePkgConf.hs:302:35: Not in scope: `ldOptions'

main/ParsePkgConf.hs:303:35: Not in scope: `frameworkDirs'

main/ParsePkgConf.hs:304:35: Not in scope: `frameworks'

main/ParsePkgConf.hs:305:35: Not in scope: `haddockInterfaces'

main/ParsePkgConf.hs:306:35: Not in scope: `haddockHTMLs'

main/ParsePkgConf.hs:307:34: Not in scope: `depends'

main/ParsePkgConf.hs:320:43: Not in scope: `depends'
>
make[2]: *** [stage2/main/ParsePkgConf.o] Error 1
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2

Warning: the following items did not execute (for ghc):
org.macports.activate org.macports.build org.macports.destroot
org.macports.install
Error: Status 1 encountered during processing.


I got the same error when trying to install ghc 6.8.2 from MacPorts on
OS X 10.4.11/Intel. It seems like the stage2 build is picking up the
wrong version of Cabal from my user packages left over from a previous
GHC 6.8.2 installation. Deleting ~/.ghc fixes the problem. Maybe the
GHC build should be changed to make sure that it doesn't use user
packages?

Björn


I'll see if I can come up with a patch to the build system that avoids  
this.

BTW, what version the Cabal in your user packages?  I was never able to
reproduce this myself --- I probably didn't stumble upon the right  
(i.e., wrong)

combination of cabals.

bw,
Greg


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

On Apr 26, 2008, at 4:58 PM, Ian Lynagh wrote:


On Thu, Apr 24, 2008 at 09:25:26AM -0400, Gregory Wright wrote:


I'll see if I can come up with a patch to the build system that  
avoids

this.


I think that this was actually done a while ago:

[pass -no-user-package-conf to ghc-inplace
Simon Marlow <[EMAIL PROTECTED]>**20080104162840] {


Thanks
Ian


I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf
flag.  Wouter, could you check if this fixes the problem you had?

bw,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: ghc 6.8.2 from MacPorts

[Gregory Wright]

Hi Wouter,

On May 1, 2008, at 11:50 AM, Wouter Swierstra wrote:



On 1 May 2008, at 13:59, Gregory Wright wrote:


I've patched MacPorts' ghc-6.8.2 to include the -no-user-package-conf
flag.  Wouter, could you check if this fixes the problem you had?


I tried a "port selfupdate" and "port clean --all ghc", followed by  
a "port install ghc". I ran into the error below (seems like another  
file-locking bug).


I Bjorn's advice (getting rid of the .ghc directory) - the build  
went through smoothly.


I'm not sure what's going on here. Hope this helps,

 Wouter

--->  Fetching ghc




'/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ 
doc/ghc/libraries/$pkg' ; \

fi
Installing: /opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/destroot/opt/local/lib/ 
ghc-6.8.2/lib/Cabal-1.2.3.0

installPackage: copyFile: resource busy (file is locked)

make[1]: *** [install.library.Cabal] Error 1
make: *** [install] Error 1

Error: Status 1 encountered during processing.


Hmmm.  If I understand correctly, doing a "port selfupdate" and "port  
clean --all"
gave a locking bug, but after you deleted .ghc, everything worked  
properly?


The locking bug looks like #2134, which is fixed by a patch in  
Macports' ghc-6.8.2.
The patch strictifies a readFile invocation in Cabal, so probably you  
were still
using the out-of-date Cabal installed as a user package.  There are  
two possible
causes: either -no-user-package-conf has a bug and doesn't always work  
right, or
you still have the previous revision of the ghc port, before the -no- 
user-package-conf
patch.  The latter can happen if there was some problem on the  
Macports server that

delayed indexing the new portfile and serving it as a selfupdate.

Can you do a "port installed ghc" and verify that you have revision 3?

Best WIshes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: *BSD support in 6.8.3

[Gregory Wright]

Hi Simon,

On May 28, 2008, at 5:05 AM, Simon Marlow wrote:


Hi Folks,

6.8.3 is nearing release, and we have an outstanding bug affecting  
the GHCi on the BSDs:


http://hackage.haskell.org/trac/ghc/ticket/2013

We need someone to help out with this.  The patch in the ticket  
apparently works, but can't be committed as is because it isn't  
correctly #ifdef'd and will presumably break other platforms.  Also  
it needs to be tested on OpenBSD/NetBSD in addition to FreeBSD.


I don't have access to a *BSD machine right now, and I don't have  
the time available to set one up.  If someone can donate a temporary  
account then that would be helpful, but most helpful would be if  
someone could work with us to get this bug fixed in time for 6.8.3  
(i.e. the next few days). Otherwise, we have to release with the bug  
still in, which would be bad.


Cheers,
Simon


I have a FreeBSD 7.0/x86_64 machine I can test this on.  Should the  
patch be applied to the

6.8.3 release candidate tarball, or just the head of the 6.8.x branch?

Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: *BSD support in 6.8.3

[Gregory Wright]

Hi Simon,

On May 29, 2008, at 11:19 AM, Simon Marlow wrote:

Ok, I've now modified the patch and attached a new version to the  
ticket:


http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch

*BSD folks please test.



I built the 20080529 snapshot with this patch and my light testing of  
ghci

showed no problems (FreeBSD 7.0/x86_64).

I will built it again tonight in a darcs checkout and run the test  
suite.  I should

be able to send back any tweaks to the patch in the next two days.

-Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: *BSD support in 6.8.3

[Gregory Wright]

Hi,

On May 29, 2008, at 11:19 AM, Simon Marlow wrote:

Ok, I've now modified the patch and attached a new version to the  
ticket:


http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch

*BSD folks please test.



I built the 20080529 snapshot with this patch and my light testing  
of ghci

showed no problems (FreeBSD 7.0/x86_64).

I will built it again tonight in a darcs checkout and run the test  
suite.  I should

be able to send back any tweaks to the patch in the next two days.

-Greg



I've built ghc 6.8.x from the darcs repository (checked out on 30 May)  
with the

2013.patch on FreeBSD 7.0/x86_64.  As far as ghci is concerned, it seems
to work and passes almost all of the tests.  However, there are many  
unexpected
failures in the testsuite, almost all apparently coming from failures  
to find mkstemp, mknod

and S_IFDIR in header files.  Either some conditional includes are
broken in ghc or FreeBSD 7.0 moved some things.  I'll have a look  
tomorrow.


-Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANN: prof2dot, version 0.4.1

[Gregory Wright]

I am pleased to announce the release of prof2dot version 0.4.1,
a graphical profiling tool for use with GHC.

The program is a filter that takes the profiling output generated by  
running

a GHC-compiled program with the "+RTS -px -RTS" option and turns it into
a dot file.  (The "dot" format is a textual representation of a  
directed or undirected graph.)

The dot file can rendered in any format supported by Graphviz's
dot program, and the file itself can be post-processed or edited to  
adjust the

layout.

The new release fixes a number of bugs and has some significant
improvements in its internal organization over the previous 0.3.1
("Premature Optimizations 'r' Us") release.

Version 0.4.1 ("Triumph of Hope Over Experience") defaults to generating
a call graph colored by number of entries into each call center.  There
is now an option to annotate the graph edges with the triple of
(cost center entries, ticks, allocations).  Module names are also given
in each cost center.

The latest version has been tested on the profiling output of some  
moderately
large programs, e.g., the profile produced by a "darcs get" of the  
entire

ghc repository:

$ darcs get http://darcs.haskell.org/ghc +RTS -px -RTS

There is also better error reporting of parser errors and consistency  
checking
of the internal graph data structure.  If anyone comes across a parse  
failure

or an assertion failure, please report it to the author.

The "dot" program from the graphviz tools is required to render the  
output of prof2dot.
Very large graphs, or graphs with extensive annotations, can exceed  
the capabilities of dot.


Prof2dot is available from Hackage in the "development" category.

-Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANN: prof2dot, version 0.4.1

[Gregory Wright]

Hi Neil,

Here's the (compressed) dot file from using darcs to get the whole
ghc repo.  It was generated by

# prof2dot darcs.prof > darcs.dot



darcs.dot.bz2
Description: application/bzip2




The structure of the file is lines defining the edges followed by lines
defining the nodes, optionally followed by subgraph definitions that  
group the
nodes into modules.  If there is a format that would make post- 
processing

easier, I can change it.

-Greg


On Aug 5, 2008, at 4:02 PM, Neil Mitchell wrote:


Hi Gregory,

Sounds fantastic. I'd love to see a single example of the resultant
.dot file, so I can figure out just how useful this might be to me.

Thanks

Neil

On Tue, Aug 5, 2008 at 8:50 PM, Gregory Wright <[EMAIL PROTECTED]>  
wrote:


I am pleased to announce the release of prof2dot version 0.4.1,
a graphical profiling tool for use with GHC.

The program is a filter that takes the profiling output generated  
by running
a GHC-compiled program with the "+RTS -px -RTS" option and turns it  
into
a dot file.  (The "dot" format is a textual representation of a  
directed or

undirected graph.)
The dot file can rendered in any format supported by Graphviz's
dot program, and the file itself can be post-processed or edited to  
adjust

the
layout.





Prof2dot is available from Hackage in the "development" category.

-Greg
___

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Version control systems

[Gregory Wright]

Hi Manuel,

On Aug 14, 2008, at 9:12 PM, Manuel M T Chakravarty wrote:

Moreover, as I wrote a few times before, some reasons for switching  
in the first place are invalidated by not having the core libraries  
in git, too.  For example, one complaint about darcs is that it  
either doesn't build (on the Sun Solaris T1 and T2 machines) or is  
buggy (on Mac OS with MacPorts), and hence people have trouble  
getting the sources out of darcs in the first place.  How is that  
going to be addressed if some crucial code still needs to be  
obtained using darcs?




Regarding darcs on OS X from MacPorts, I am not aware (or have been  
sent any bug reports) that there
are problems with the latest darcs-2.0.0 port.  Is there something  
that I should know (and try to fix)?


The latest port defaults to wget instead of libcurl since I have  
noticed darcs spinning endlessly when
using libcurl.  I haven't had time to dtrace what is going on but I'm  
guessing the underlying problem is likely
some misunderstanding of the signal handling API or some corner case  
of blocking/nonblocking IO.


-Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: has anyone built pandoc with MacPorts ?

[Gregory Wright]

Hi Denis,

I haven't built pandoc yet --- I didn't do the port --- but I'll have  
a go at it tonight and

let you know what I find.

BTW, did you run

$ sudo port selfupdate

before starting to make sure you had the latest Portfiles for  
everything?


Best Wishes,
Greg


On Oct 10, 2008, at 4:45 PM, denis wrote:


Greg, folks,

port install ghc worked after 7 hours or so, but then

sudo port -v install hs-ghc-paths (on which pandoc apparently depends)
=>
# from: sudo port -v install hs-ghc-paths
# run: 10 Oct 2008 22:35  in /opt/local Denis.local  mac 10.4.11 ppc

--->  Configuring hs-ghc-paths

Setup.hs:7:7:
  Could not find module `Distribution.Simple.PackageIndex':
Use -v to see a list of the files searched for.
Error: Target org.macports.configure returned: shell command "cd / 
opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_devel_hs-ghc-paths/work/ghc- 
paths-0.1.0.5 && runhaskell Setup configure --ghc --prefix=/opt/ 
local" returned error 1

Command output:
Setup.hs:7:7:
  Could not find module `Distribution.Simple.PackageIndex':
Use -v to see a list of the files searched for.

Warning: the following items did not execute (for hs-ghc-paths):  
org.macports.activate org.macports.configure org.macports.build  
org.macports.destroot org.macports.install

Error: Status 1 encountered during processing.


Has anyone ever built pandoc with MacPorts ?  Would appreciate your  
help.


cheers
  -- denis


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: has anyone built pandoc with MacPorts ?

[Gregory Wright]

Hi,

On Oct 10, 2008, at 4:45 PM, denis wrote:


Greg, folks,

port install ghc worked after 7 hours or so, but then

sudo port -v install hs-ghc-paths (on which pandoc apparently depends)
=>
# from: sudo port -v install hs-ghc-paths
# run: 10 Oct 2008 22:35  in /opt/local Denis.local  mac 10.4.11 ppc

--->  Configuring hs-ghc-paths

Setup.hs:7:7:
  Could not find module `Distribution.Simple.PackageIndex':
Use -v to see a list of the files searched for.
Error: Target org.macports.configure returned: shell command "cd / 
opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_devel_hs-ghc-paths/work/ghc- 
paths-0.1.0.5 && runhaskell Setup configure --ghc --prefix=/opt/ 
local" returned error 1

Command output:
Setup.hs:7:7:
  Could not find module `Distribution.Simple.PackageIndex':
Use -v to see a list of the files searched for.

Warning: the following items did not execute (for hs-ghc-paths):  
org.macports.activate org.macports.configure org.macports.build  
org.macports.destroot org.macports.install

Error: Status 1 encountered during processing.


Has anyone ever built pandoc with MacPorts ?  Would appreciate your  
help.


cheers
  -- denis


Pandoc built fine for me on Mac OS X 10.5.5/intel with ghc 6.8.3, hs- 
ghc-paths 0.1.0.5
and haddock 2.2.2.  What version of the ghc port are you using (i.e.,  
the output of


$ port info ghc

?

Also, do you have more than one version of cabal on your system?

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC on powerpc (OS X): segmentation fault

[Gregory Wright]

Hi Chrisitian,

On Nov 11, 2008, at 7:19 AM, Christian Maeder wrote:


Chris Kuklewicz wrote:

Christian Maeder wrote:

I can offer a Tiger PPC built that works for me:
(linked against /opt/local/lib/libgmp.dylib)



But the filename says "-i386-" so I suspect it is not a powerpc  
build.


Sorry, the link is:

http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.10.1-powerpc-apple-darwin.tar.bz2

Christian


I'll try using your binary compiler as a bootstrap compiler for the  
macports' ppc

builds.  Should have something ready for testing in a day or two.

Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Notes on building 6.10.1

[Gregory Wright]

Hi,

When building 6.10.1 under Macports, I noticed that hpc now requires  
that hsc2hs
be present on the system (it does not use the hsc2hs built in place  
with the new ghc).
Previous versions did not require hsc2hs to be present; the compiler  
could be

bootstrapped from just the ghc compiler and ghc-pkg.

The hpc library is the only one that requires the external hsc2hs.  Is  
this new dependency

intentional, or is this a build system bug?

This problem escaped detection initially because cabal will use any  
hsc2hs on the path
even if the --with-compiler flag is set.  (--with-compiler forces a  
particular compiler and
packaging program, but not hsc2hs.)  This is just asking for trouble.   
For the moment,
it's fixed in the Macports build by hacking hpc's Makefile to specify  
--with-hsc2hs.


Should cabal produce and error or a warning if hsc2hs is not found in  
the same directory
as the compiler?  I suggest an error by default, but not if --with- 
hsc2hs is given explicitly.


Best Wishes,
Greg





___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Notes on building 6.10.1

[Gregory Wright]

Hi Ian,

On Nov 12, 2008, at 5:52 PM, Ian Lynagh wrote:


On Wed, Nov 12, 2008 at 12:42:00PM -0500, Gregory Wright wrote:


The hpc library is the only one that requires the external hsc2hs.   
Is

this new dependency
intentional, or is this a build system bug?


I don't think that the build dep is necessary, but with the current
filesystem layout it's a pain to avoid. We would need to, with the
bootstrapping compiler:

Build libraries/{filepath,Cabal,cabal-bin}
Build utils/hsc2hs
Build libraries/hpc
Build compiler (stage 1)

We plan to rewrite the build system for 6.12 anyway, so I think we
should take care of this then. It probably makes sense to merge (some
of?) "utils" and "libraries" into "packages".

As far as 6.10 is concerned, we install hsc2hs with ghc by default,  
so I

think it is reasonable to depend on it.



OK. I'll file a placeholder bug report so this doesn't get forgotten.
I understand the reason for leaving it as is for now, but hope that we
avoid creeping dependence on more tools.

BTW, now that ghc distributes its own version of haddock, could that
version be renamed to avoid the obvious namespace clash?  Macports
will rename ghc's haddock to haddock-ghc so it doesn't conflict with
the one installed from hackage.  Or is there a better plan?

Best Wishes,
Greg




___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

[Gregory Wright]

Hi Jason,

On Nov 21, 2008, at 8:09 AM, Jason Dagit wrote:


On Wed, Nov 19, 2008 at 1:28 AM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:

Jason Dagit:

On Wed, Nov 5, 2008 at 5:36 PM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:


Ian Lynagh:


On Tue, Nov 04, 2008 at 09:02:12PM -0500, Brandon S. Allbery  
KF8NH wrote:


On 2008 Nov 4, at 20:26, Jason Dagit wrote:


On Tue, Nov 4, 2008 at 4:26 PM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:


Are you sure it does deinstall the 6.8 compiler?

After installing 6.10, there should be a 608/ and a 610/
directory.  This
certainly happens on my Mac and I am not aware of an option to
change that
behaviour.


I expect if you used the OSX installer then /Library/Receipts is
screwing you (it wipes the old files listed in the .bom file).   
Try

finding and removing the receipt directory and bom file before
installing.


The only file I can see that looks relevant is
 /Library/Receipts/boms/ 
org.haskell.glasgowHaskellCompiler.ghc.pkg.bom


Wouldn't removing it make uninstall impossible?

In fact, if you did manage to get 2 versions installed, how would
 /Library/Frameworks/GHC.framework/Tools/Uninstaller
know which version to uninstall? Wouldn't it only know how to  
uninstall

the version it came with? I'd suggest that the overlapping file
"Uninstaller" could be why the older version gets removed, but that
wouldn't explain why Manuel can install both at once.


A current limitation of the MacOS package system is that it does not
support uninstalling of packages; cf


http://developer.apple.com/documentation/DeveloperTools/Conceptual/SoftwareDistribution/Managed_Installs/chapter_5_section_7.html#/ 
/apple_ref/doc/uid/1145i-CH6-DontLinkElementID_29


This is not a big drama on MacOS, as MacOS encourages the  
distribution of

software packages as "bundles":


http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/CFBundles.html

This essentially means that instead of sprinkling files all over  
the file
system (as is common in other OSes), MacOS applications and  
frameworks
(Mac-speak for libraries) are kept in a single directory.   
Uninstalling then

means doing an rm -rf on that directory.

Unfortunately, some applications (including GHC and Apple's Xcode  
IDE)
can't be entirely contained in a single directory.  In the case of  
GHC, we

want symlinks in /usr/bin.  The established way of uninstalling such
applications is by supplying an Uninstaller script, just as I did  
for GHC.

(Apple does the same for Xcode.)

The purpose of the Uninstaller script is too completely remove
GHC.framework from a machine - not just to remove one version.  In  
fact, if
more than one version of GHC is installed, the Uninstaller will  
refuse to
run and require the manual removal of all versions, but the  
current (easily

achieved by a "rm -rf
/Library/Frameworks/GHC.framework/Versions/").  The main  
feature of

the Uninstaller script is to get rid of all symlinks pointing into
GHC.framework.  The framework itself is just deleted by a "rm -rf"  
as

expected.  (It also removes the above mentioned receipt file.)

So, to directly answer the above questions:
* The package manger (which uses the receipts) can't uninstall and  
the
uninstaller script doesn't need the receipt.  So, even after  
deleteing the

receibt, you can still uninstall.
* The Uninstaller can uninstall any version (at least as long as no
symlinks are put into new directories outside of the bundle that the
Uninstaller doesn't know about).


Is there an update on this thread?  I would still like to have my  
cake and

eat it too, meaning ghc 6.8.3 and ghc 6.10.1.  As far as I know the
installer hasn't been updated and if I try again I will lose my  
copy of

6.8.3.

Sorry, but for the moment, my (rather limited knowledge) of the
MacOS packaging system is exhausted, and currently I don't have the  
time to
search the web or experiment to try to learn more.  It would be  
helpful to
have the input of somebody who has more experience with MacOS  
packages.

Manuel


Okay.  That's fine, the OSX installer system sounds odd.  I don't want
to fight with it myself.  I just want to upgrade ghc and I was getting
pressure to do so and I tried the .tar.bz version, but I had some
annoying experiences that I can share.

So, the page here:
http://www.haskell.org/ghc/download_ghc_6_10_1.html#macosxintel

Has only this as installation instructions:
This is a binary distribution for Mac OS X 10.5 (Leopard), prepared by
Christian Maeder. It needs libedit.2.dylib, libncurses.5.dylib and
libgmp.3.dylib under /opt/local/lib/.

I had no idea how to do the install or how to satisfy the
requirements.  By pestering others I learned that you install
libraries into /opt/local using MacPorts.  The next challenge was
learning what to do with the .tar.bz file once it was downloaded.  I
found an INSTALL file inside the tarball with some instructions
thankfully.  I wish the download page said something

Re: ANNOUNCE: GHC version 6.10.1 - MacOS installer

[Gregory Wright]

Hi Thorkil,

On Nov 21, 2008, at 11:03 AM, Thorkil Naur wrote:


Hello Greg,

On Friday 21 November 2008 15:56, Gregory Wright wrote:

...
ppc/
Leopard still
fails, but I now have an account on a machine that I can use to test
and debug.


And if you need such an access (now or in the future), please just  
say the

word and you can get access to my PPC Mac OS X 10.5 Leopard machine.


...


Best regards
Thorkil


Thank you for your kind offer.  I will likely take you up on it in the  
future.


Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Preferred gcc for use with ghc

[Gregory Wright]

Hi,

What is the preferred gcc to use with ghc 6.10.1?  I'm starting
the long and doubtless slow process of putting together a more user
friendly (and binary distributable) ghc distribution to be built using  
MacPorts.

The guidance about gcc on the wiki is vague.  Is there a best choice?
Or at least some versions to be avoided?

Best,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC

[Gregory Wright]

Hi David,

On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote:


David Menendez wrote:

I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4
running OS X 10.5.5. From what I can tell, I'm getting a segmentation
fault from cabal-bin.


On PPC leopard you need to update to XCode 3.1
http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX
http://hackage.haskell.org/trac/ghc/ticket/2887

HTH Christian



It would be very helpful to know if this solves the problem for you.   
I've had reports
of similar failures on 10.4, but have not been able to reproduce them  
on a ppc/10.4 machine

or a ppc/10.5 machine.

Even with Xcode 3.0, it seems as if not everyone gets tagged by the  
error.


Greg



This is possibly related to 
and .


cd extensible-exceptions &&
/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ 
cabal-bin
/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ 
bootstrapping.conf

configure --distpref=dist-bootstrapping
--with-compiler=/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
--with-hc-pkg=/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg
--package-db=/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ 
bootstrapping.conf.tmp

/bin/sh: line 1: 19203 Segmentation fault
/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ 
cabal-bin
/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ 
bootstrapping.conf

configure --distpref=dist-bootstrapping
--with-compiler=/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc
--with-hc-pkg=/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg
--package-db=/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync 
.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ 
bootstrapping.conf.tmp

make[1]: *** [bootstrapping.conf] Error 139
make: *** [stage1] Error 2





___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1

[Gregory Wright]

I built ghc-6.10.1.20090314 on OS X 10.5.6 (Intel) using ghc 6.8.2 as
a bootstrap compiler.  The build was done using the MacPorts  
infrastructure.


Summary test results:

OVERALL SUMMARY for test run started at Tue Mar 17 15:31:38 EDT 2009
2334 total tests, which gave rise to
   12487 test cases, of which
   0 caused framework failures
2460 were skipped

9709 expected passes
 258 expected failures
   0 unexpected passes
  60 unexpected failures

Unexpected failures:
   2469(ghci)
   apirecomp001(normal)

bits 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)

   conc049(hpc)
   conc068(normal)
   derefnull(profc,profthreaded)
   divbyzero(profc,profthreaded)

genUpTo 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)

   length001(optc,hpc,optasm,profc,profasm,threaded2,profthreaded)

num009 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)

num012 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)

   signals002(ghci)
   signals004(ghci,threaded1,threaded2,profthreaded)


I haven't looked at the errors in detail, but generally the release  
candidate

seems OK.

BTW, a test target will be added to MacPorts's portfile for the 6.10.2  
release, which will

let you run the test suite by typing

> sudo port test ghc

and if you then install the tested build, a record of the test will be  
saved in

$PREFIX/share/ghc-/.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Under OS X 10.5.6: GHC 6.10.1 Release Candidate 1

[Gregory Wright]

Hi Thomas,


On Mar 18, 2009, at 10:03 AM, Thomas Schilling wrote:

There should be a file called testlog somewhere, either at the  
toplevel or within the tests directory.  Could you search for  
"apirecomp001" and send me the test output from running that test.   
I can't reproduce this failure when running it manually even though  
I'm on OS X, too.




I get:

> Running ./ghc-api/apirecomp001/all.T
=> apirecomp001(normal)cd ./ghc-api/apirecomp001 && $MAKE -s --no- 
print-directory apirecomp001apirecomp001.run.stdout  
2>apirecomp001.run.stderr

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
ld warning: atom sorting error for  
_ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and  
_ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ 
var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- 
beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ 
libHSghc-6.10.1.20090314.a(LibFFI.o)
ld warning: atom sorting error for  
_ghczm6zi10zi1zi20090314_LibFFI_Czuffizutype_closure_tbl and  
_ghczm6zi10zi1zi20090314_LibFFI_Czuffizucif_closure_tbl in /opt/local/ 
var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc- 
beta/work/ghc-6.10.1.20090314/compiler/dist-stage2/build/ 
libHSghc-6.10.1.20090314.a(LibFFI.o)

make[2]: myghc: Command not found
make[2]: *** [apirecomp001] Error 127
*** unexpected failure for apirecomp001(normal)


Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-6.10.3-pre on OS X 10.5.6

[Gregory Wright]

Hi,

I built ghc-6.10.2.20090504 on OS X 10.5.6 (Intel).  The build  
succeeded, and the results

of running the 6.10.2 (release) testsuite were:

OVERALL SUMMARY for test run started at Wed May  6 04:21:54 EDT 2009
2413 total tests, which gave rise to
   12919 test cases, of which
   0 caused framework failures
2489 were skipped

   10033 expected passes
 301 expected failures
   0 unexpected passes
  96 unexpected failures

Unexpected failures:
   2469(ghci)
   2816(ghci)
   DoParamM(normal)
   jl_defaults(ghci)
   jules_xref(ghci)
   jules_xref2(ghci)
   launchbury(ghci)
   lex(ghci)
   mod133(normal)

num009 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)

reify 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)

   rittri(ghci)
   signals002(ghci,ghci)

signals004 
(ghci 
,threaded1,threaded2,profthreaded,ghci,threaded1,threaded2,profthreaded)

   tc183(normal,optc,hpc,optasm,profc,profasm)
   tc217(normal,optc,hpc,optasm,profc,profasm)
   tc220(normal,optc,hpc,optasm,profc,profasm)
   tc223(normal,optc,hpc,optasm,profc,profasm)
   tc232(normal,optc,hpc,optasm,profc,profasm)
   tcfail126(normal)

tree 
(normal 
,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2,profthreaded)



(I assume that I should be testing with the latest released testsuite  
in the absence of a

snapshot. Is that true?)

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.10.4 Release Candidate 1

[Gregory Wright]

Good rc1 build on OS X 10.5.7 (Leopard/intel). Couldn't run the 6.10.3 
testsuite all the way through. Failed with things like


=> getGroupEntryForName(normal)
cd ../../../libraries/unix/tests && 
'/opt/local/var/macports/build/_Users_gwright_src_macports-trunk_dports_lang_ghc-beta/work/ghc-6.10.3.20090628/ghc/stage2-inplace/ghc' 
-fforce-recomp -dcore-lint -dcmm-lint  -dno-debug-output -o 
getGroupEntryForName getGroupEntryForName.hs  -package unix  

getGroupEntryForName.comp.stderr 2>&1
cd ../../../libraries/unix/tests && ./getGroupEntryForName
getGroupEntryForName.run.stdout 2>getGroupEntryForName.run.stderr

Wrong exit code (expected 0 , actual 1 )
Stdout:

Stderr:
getGroupEntryForName: thisIsNotMeantToExist: getGroupEntryForName: does 
not exist (no group name)



Should I be running a different version of the tests?

Best Wishes,
Greg

--
Gregory Wright
Antiope Associates LLC
18 Clay Street
Fair Haven, New Jersey 07704
USA

gwri...@antiope.com

+1 (732) 924-4549
+1 (732) 345-8378 [fax]



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.10.4

[Gregory Wright]

Hi Yitz,

Yitzchak Gale wrote:

   The (Interactive) Glasgow Haskell Compiler -- version 6.10.4
How to get it
   http://www.haskell.org/ghc/



I have a few comments about the "Distribution Packages" page
that is linked from there:

http://www.haskell.org/ghc/distribution_packages.html

Debian:

Remove the line "Newer packages may be available in Haskell Unsafe."
That stuff is very, very old.

Mac OS X:

Paragraph beginning "Contrary to the recommendation at
the top of this page... rather than using the alternatives
below." It makes no sense. It appears to be referring to
an older version of the page.

"Both 10.3 (Panther) and 10.4 (Tiger) are supported."
should be changed to 10.4 (Tiger) and 10.5 (Leopard).

The paragraph about the ghc-devel port should be removed,
I think. The port still exists, but it doesn't seem to be actively
supported since 6.7. Anyone who wants to use GHC HEAD
will probably just build current HEAD manually. (Greg - is
this correct?)

  
The ghc-devel port is not supported now. I will modify it to print a 
message to

that effect.  When there is a more reliable procedure for development builds
is available I can re-enable the port.

Thanks,
Yitz

  


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc ftp site

[Gregory Wright]

Hi,

Could someone tell me who is in charge of the ghc ftp site these days?
I need to upload a bootstrap compiler to build MacPort's ghc on Snow
Leopard and the permissions of the 6.10 - 6.1 directories have changed.
I no longer can write there.

Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANNOUNCE: haskell-platform on MacPorts

[Gregory Wright]

Hi,

The haskell-platform, version 2009.2.0.2, is now available from MacPorts.

For those unfamiliar with MacPorts, it a build-from-source system for OS 
X similar

to the port system used in BSD distributions.  More information
is available from http://macports.org.

Once MacPorts is installed, you can build the haskell platform by typing

> sudo port install haskell-platform

On a reasonably fast MacBook, this takes an hour and a half to two hours.
If you want to watch the excitement scroll past, try

> sudo port -d install haskell-platform

The platform contains an updated port of ghc-6.10.4 which now builds
automagically on 32 and 64 bit Snow Leopard.  (It can also be forced to
build 32 bit on a 64 bit Snow Leopard by setting the "build_arch" variable
to i386 in the macports.conf file.)

The 64 bit port was cribbed from the excellent work of Barney Stratford
for fink.  Thanks as well to Marco Comini, Tom Hutchinson, Ian Lynagh,
John Peterson, Ryan Schmidt and Falk Schramm for their help.

Best Wishes,
Greg Wright

--
Gregory Wright
Antiope Associates LLC
18 Clay Street
Fair Haven, New Jersey 07704
USA

gwri...@antiope.com

+1 (732) 924-4549
+1 (732) 345-8378 [fax]

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Profiling bug in 6.10.4

[Gregory Wright]

Hi,

I have a program (attached) that is relatively simple, but numerically 
intensive.

It computes the abundances of the chemical elements generated by big-bang
nucleosynthesis.  At the moment, the executable takes no command line 
arguments,

it simply runs the standard model.

When I build the program without profiling, it produces the right 
answer.  When
I build it with profiling (runhaskell configure 
--enable-executable-profiling) it runs
without error, but gives completely incorrect numerical results.  I'm 
using ghc 6.10.4

built from source using MacPorts.

The program is mostly self contained, but uses the hmatrix package to 
solve a linear
system.  Note also that the "Vector" type is hmatrix's 
Data.Packed.Vector and not

the one from the more familiar "vector" package.

I was wondering whether this profiling problem is known.

Best Wishes,
Greg


Nsyn-0.5.tar.gz
Description: GNU Zip compressed data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Profiling bug in 6.10.4

[Gregory Wright]

Hi,

On 3/22/10 10:22 AM, Gregory Wright wrote:


Hi,

I have a program (attached) that is relatively simple, but numerically 
intensive.

It computes the abundances of the chemical elements generated by big-bang
nucleosynthesis.  At the moment, the executable takes no command line 
arguments,

it simply runs the standard model.

When I build the program without profiling, it produces the right 
answer.  When
I build it with profiling (runhaskell configure 
--enable-executable-profiling) it runs
without error, but gives completely incorrect numerical results.  I'm 
using ghc 6.10.4

built from source using MacPorts.

The program is mostly self contained, but uses the hmatrix package to 
solve a linear
system.  Note also that the "Vector" type is hmatrix's 
Data.Packed.Vector and not

the one from the more familiar "vector" package.

I was wondering whether this profiling problem is known.

Best Wishes,
Greg
   

The previously attach tarball was missing most of its contents, courtesy
of my ham-fisted emacs technique.  The tarball attached to this message has
been tested by building and shows the problem mentioned above.

-Greg


Nsyn-0.6.tar.gz
Description: GNU Zip compressed data
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Profiling bug in 6.10.4

[Gregory Wright]

Hi Krzysztof,

On 3/22/10 2:42 PM, Krzysztof Skrzętnicki wrote:

I got some results from  GHC 6.12.1, Linux i686. In short: both
profiling and normal run produce the same final results, but there are
some differences. I don't know if they are valid or not.

./nsyn | tail
1080826.599  0.01   8.483e-157.612e-17.753e-52.517e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1134406.808  0.01   6.911e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1191190.672  0.01   5.615e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1251481.495  0.01   4.548e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1315638.396  0.01   3.671e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1384093.315  0.01   2.952e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1457375.318  0.01   2.364e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1535826.102  0.01   1.884e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1619603.195  0.01   1.495e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1709306.677  0.01   1.180e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16

  ./nsyn-prof | tail
1080826.599  0.01   8.483e-157.612e-17.753e-52.517e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1134406.808  0.01   6.911e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1191190.672  0.01   5.615e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1251481.495  0.01   4.548e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1315638.396  0.01   3.671e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1384093.315  0.01   2.952e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1457375.318  0.01   2.364e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1535826.102  0.01   1.884e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1619603.195  0.01   1.495e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1709306.677  0.01   1.180e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16

Best regards

Krzysztof Skrzętnicki

2010/3/22 Gregory Wright:
   

Hi,

On 3/22/10 10:22 AM, Gregory Wright wrote:
 

Hi,

I have a program (attached) that is relatively simple, but numerically
intensive.
It computes the abundances of the chemical elements generated by big-bang
nucleosynthesis.  At the moment, the executable takes no command line
arguments,
it simply runs the standard model.

When I build the program without profiling, it produces the right answer.
  When
I build it with profiling (runhaskell configure
--enable-executable-profiling) it runs
without error, but gives completely incorrect numerical results.  I'm
using ghc 6.10.4
built from source using MacPorts.

The program is mostly self contained, but uses the hmatrix package to
solve a linear
system.  Note also that the "Vector" type is hmatrix's Data.Packed.Vector
and not
the one from the more familiar "vector" package.

I was wondering whether this profiling problem is known.

Best Wishes,
Greg

   

The previously attach tarball was missing most of its contents, courtesy
of my ham-fisted emacs technique.  The tarball attached to this message has
been tested by building and shows the problem mentioned above.

-Greg

 


   


Now they seem to both be correct.  The key value is at the bottom of 
column 8.  This should be 2.386e-1
(which means that 23.86 percent of the protons in the early universe end 
up as helium).  So it

seems that this is a problem either with 6.10.4, or with OS X.

Quite strange.  I will try to get 6.12 building on my machine to see if 
the problem persists.


-Greg
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Profiling bug in 6.10.4

[Gregory Wright]

On OS X 10.5.9 with ghc 6.10.4 with no  profiling I get :

1315638.396  0.01   3.671e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1384093.315  0.01   2.952e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1457375.318  0.01   2.364e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1535826.102  0.01   1.884e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1619603.195  0.01   1.495e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1709306.677  0.01   1.180e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16


but with profiling turned on I get

1301464.458  0.018.545e-19.002e-1   3.312e-12   5.820e-24   
6.174e-24   1.367e-34   1.505e-58   3.780e-70   3.586e-70   7.960e-82
1379801.447  0.018.545e-19.293e-1   3.312e-12   5.820e-24   
6.174e-24   1.411e-34   1.505e-58   3.780e-70   3.586e-70   7.960e-82
1462853.640  0.018.545e-19.596e-1   3.312e-12   5.820e-24   
6.174e-24   1.458e-34   1.505e-58   3.780e-70   3.586e-70   7.960e-82
1550904.850  0.018.545e-19.947e-1   3.312e-12   5.820e-24   
6.174e-24   1.511e-34   1.505e-58   3.780e-70   3.586e-70   7.960e-82
1644255.972  0.018.545e-1 1.032e0   3.312e-12   5.820e-24   
6.174e-24   1.568e-34   1.505e-58   3.780e-70   3.586e-70   7.960e-82
1743226.010  0.018.545e-1 1.074e0   3.312e-12   5.820e-24   
6.174e-24   1.631e-34   1.505e-58   3.780e-70   3.586e-70   7.960e-82


It's not just a matter of some addition numerical inaccuracy; the 
numbers are off by

orders of magnitude.

-Greg

On 3/22/10 2:42 PM, Krzysztof Skrzętnicki wrote:

I got some results from  GHC 6.12.1, Linux i686. In short: both
profiling and normal run produce the same final results, but there are
some differences. I don't know if they are valid or not.

./nsyn | tail
1080826.599  0.01   8.483e-157.612e-17.753e-52.517e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1134406.808  0.01   6.911e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1191190.672  0.01   5.615e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1251481.495  0.01   4.548e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1315638.396  0.01   3.671e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1384093.315  0.01   2.952e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1457375.318  0.01   2.364e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1535826.102  0.01   1.884e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1619603.195  0.01   1.495e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1709306.677  0.01   1.180e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16

  ./nsyn-prof | tail
1080826.599  0.01   8.483e-157.612e-17.753e-52.517e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1134406.808  0.01   6.911e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1191190.672  0.01   5.615e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1251481.495  0.01   4.548e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1315638.396  0.01   3.671e-157.612e-17.753e-52.516e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1384093.315  0.01   2.952e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1457375.318  0.01   2.364e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1535826.102  0.01   1.884e-157.612e-17.753e-52.515e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1619603.195  0.01   1.495e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16
1709306.677  0.01   1.180e-157.612e-17.753e-52.514e-7
1.566e-52.387e-1   3.089e-14   6.337e-11   5.791e-11   5.665e-16

Best regards

Krzysztof Skrzętnicki

2010/3/22 Gregory Wright:
   

Hi,

On 3/22/10 10:22 AM, Gregory Wright wrote:
   

Re: Profiling bug in 6.10.4

[Gregory Wright]

On 3/31/10 11:44 AM, Ian Lynagh wrote:

On Mon, Mar 22, 2010 at 02:54:26PM -0400, Gregory Wright wrote:
   

Now they seem to both be correct.  The key value is at the bottom of
column 8.  This should be 2.386e-1
(which means that 23.86 percent of the protons in the early universe end
up as helium).  So it
seems that this is a problem either with 6.10.4, or with OS X.

Quite strange.  I will try to get 6.12 building on my machine to see if
the problem persists.
 

It would also be worth trying without the -optc-O3 and -optc-ffast-math
flags, as the different code generated may confuse the mangler.

If none of that helps, can you file a ticket please? If you can boil it
down to a small self-contained testcase (in particular, removing the
hmatrix dependency, if necessary by inlining code you need from it)
that would make it easier to investigate.


Thanks
Ian


   
Removing -optc-O3 and -optc-ffast-math did not help.  In fact, I took at 
all of the
ghc options I was passing and the problem is still there. I will try to 
reduce the failure
to a self contained testcase.   I don't use much from hmatrix --- aside 
from the LU
solution for a matrix system, just basic matrix addition, subtraction, 
scaling and the

dot product.

Best,
Greg



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Mac Port

[Gregory Wright]

On Sunday, June 1, 2003, at 05:15 AM, Wolfgang Thaller wrote:

Seth Kurtzberg wrote:

Is there, or is anyone working on, ports for Mac OSX and/or Mac OS9?
I'm currently responsible for the Mac OS X version of GHC. I'll upload 
a GHC 6.0 binary for Mac OS X binary as soon as possible, but I'm 
short on time and processor cycles, so it might take a few more days.
I could definitely use more people who regularily build GHC on MacOS X 
and do some testing, and alert me of any breakage _before_ I make a 
buggy release... I don't have the computing capacity to do nightly 
builds.

Dear Wolfgang,

I maintain the Hugs port for the darwinports system (a cousin of fink 
and
perhaps the successor to the *bsd ports system). I'd like to add a port
for ghc-6.0. I tried to build it but ran into some problems.

1. configure doesn't pass the CPPFLAGS and LDFLAGS environment variables
to the haskell build. This means you can't have libreadline and libdl in
non-standard locations.
This is a problem for darwinports and fink because of their automatic 
dependency
management.

2. Even if I put symlinks to the above libraries in the standard 
locations,
I still get a build failure. This is building 6.0 using 5.04.3. (5.04.3 
was
built from source successfully using your 5.04.2 binary.) The build 
ends with

../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.0 -H16m -O  
-istage2/utils  -istage2/basicTypes  -istage2/types  -istage2/hsSyn  
-istage2/prelude  -istage2/rename  -istage2/typecheck  -istage2/deSugar 
 -istage2/coreSyn  -istage2/specialise  -istage2/simplCore  
-istage2/stranal  -istage2/stgSyn  -istage2/simplStg  -istage2/codeGen  
-istage2/absCSyn  -istage2/main  -istage2/profiling  -istage2/parser  
-istage2/cprAnalysis  -istage2/compMan  -istage2/ndpFlatten  
-istage2/nativeGen  -istage2/ghci -DGHCI -package haskell-src -package 
unix -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen 
-Iparser -recomp -Rghc-timing  -H16M '-#include "hschooks.h"'
-no-link-chk stage2/absCSyn/AbsCSyn.o  stage2/absCSyn/AbsCUtils.o  
stage2/absCSyn/CLabel.o  stage2/absCSyn/CStrings.o  
stage2/absCSyn/Costs.o  stage2/absCSyn/MachOp.o  
stage2/absCSyn/PprAbsC.o  stage2/basicTypes/BasicTypes.o  
stage2/basicTypes/DataCon.o  stage2/basicTypes/Demand.o  
stage2/basicTypes/FieldLabel.o  stage2/basicTypes/Id.o  
stage2/basicTypes/IdInfo.o  stage2/basicTypes/Literal.o  
stage2/basicTypes/MkId.o  stage2/basicTypes/Module.o  
stage2/basicTypes/Name.o  stage2/basicTypes/NameEnv.o  
stage2/basicTypes/NameSet.o  stage2/basicTypes/NewDemand.o  
stage2/basicTypes/OccName.o  stage2/basicTypes/RdrName.o  
stage2/basicTypes/SrcLoc.o  stage2/basicTypes/UniqSupply.o  
stage2/basicTypes/Unique.o  stage2/basicTypes/Var.o  
stage2/basicTypes/VarEnv.o  stage2/basicTypes/VarSet.o  
stage2/codeGen/Bitmap.o  stage2/codeGen/CgBindery.o  
stage2/codeGen/CgCase.o  stage2/codeGen/CgClosure.o  
stage2/codeGen/CgCon.o  stage2/codeGen/CgConTbls.o  
stage2/codeGen/CgExpr.o  stage2/codeGen/CgHeapery.o  
stage2/codeGen/CgLetNoEscape.o  stage2/codeGen/CgMonad.o  
stage2/codeGen/CgRetConv.o  stage2/codeGen/CgStackery.o  
stage2/codeGen/CgTailCall.o  stage2/codeGen/CgUpdate.o  
stage2/codeGen/CgUsages.o  stage2/codeGen/ClosureInfo.o  
stage2/codeGen/CodeGen.o  stage2/codeGen/SMRep.o  
stage2/compMan/CompManager.o  stage2/coreSyn/CoreFVs.o  
stage2/coreSyn/CoreLint.o  stage2/coreSyn/CorePrep.o  
stage2/coreSyn/CoreSyn.o  stage2/coreSyn/CoreTidy.o  
stage2/coreSyn/CoreUnfold.o  stage2/coreSyn/CoreUtils.o  
stage2/coreSyn/ExternalCore.o  stage2/coreSyn/MkExternalCore.o  
stage2/coreSyn/PprCore.o  stage2/coreSyn/PprExternalCore.o  
stage2/coreSyn/Subst.o  stage2/cprAnalysis/CprAnalyse.o  
stage2/deSugar/Check.o  stage2/deSugar/Desugar.o  
stage2/deSugar/DsBinds.o  stage2/deSugar/DsCCall.o  
stage2/deSugar/DsExpr.o  stage2/deSugar/DsForeign.o  
stage2/deSugar/DsGRHSs.o  stage2/deSugar/DsListComp.o  
stage2/deSugar/DsMeta.o  stage2/deSugar/DsMonad.o  
stage2/deSugar/DsUtils.o  stage2/deSugar/Match.o  
stage2/deSugar/MatchCon.o  stage2/deSugar/MatchLit.o  
stage2/ghci/ByteCodeAsm.o  stage2/ghci/ByteCodeFFI.o  
stage2/ghci/ByteCodeGen.o  stage2/ghci/ByteCodeInstr.o  
stage2/ghci/ByteCodeItbls.o  stage2/ghci/ByteCodeLink.o  
stage2/ghci/InteractiveUI.o  stage2/ghci/Linker.o  
stage2/ghci/ObjLink.o  stage2/hsSyn/Convert.o  stage2/hsSyn/HsBinds.o  
stage2/hsSyn/HsCore.o  stage2/hsSyn/HsDecls.o  stage2/hsSyn/HsExpr.o  
stage2/hsSyn/HsImpExp.o  stage2/hsSyn/HsLit.o  stage2/hsSyn/HsPat.o  
stage2/hsSyn/HsSyn.o  stage2/hsSyn/HsTypes.o  stage2/main/BinIface.o  
stage2/main/CmdLineOpts.o  stage2/main/CodeOutput.o  
stage2/main/Config.o  stage2/main/Constants.o  
stage2/main/DriverFlags.o  stage2/main/DriverMkDepend.o  
stage2/main/DriverPhases.o  stage2/main/DriverPipeline.o  
stage2/main/DriverState.o  stage2/main/DriverUtil.o  
stage2/main/ErrUtils.o  stage2/main/Finder.o  stage2/main/GetImports.o  
stage2/main/HscMain.o  stage2/main/HscStats.o  stage2/main/HscTypes.o  
s

Re: Mac Port

[Gregory Wright]

On Sunday, June 1, 2003, at 07:36 PM, Wolfgang Thaller wrote:

Dear Wolfgang,

I maintain the Hugs port for the darwinports system (a cousin of fink 
and
perhaps the successor to the *bsd ports system). I'd like to add a 
port
for ghc-6.0. I tried to build it but ran into some problems.

1. configure doesn't pass the CPPFLAGS and LDFLAGS environment 
variables
to the haskell build. This means you can't have libreadline and libdl 
in
non-standard locations.
Grmpf... I know I don't like configure scripts. I prefer IDEs. Do you 
know how to fix it/have time to do it?
If not, would somebody else _PLEASE_ do that for us? (It wouldn't 
enjoy digging into the build system code to fix that; in fact, I would 
positively hate it).

I will take a look at the configuration issue for ghc-6.0 + Mac OS X. I 
was
able to hand edit the makefiles to pass the correct include and library 
paths;
it's not too big a job to pass the appropriate configuration variables.


This is a problem for darwinports and fink because of their automatic 
dependency
management.

2. Even if I put symlinks to the above libraries in the standard 
locations,
I still get a build failure. This is building 6.0 using 5.04.3. 
(5.04.3 was
built from source successfully using your 5.04.2 binary.) The build 
ends with
[...]
Ahem, yes. I didn't have a chance to test GHC 6 in the last five days 
before the release, and, of course, the last commit broke the Mac OS X 
build. I have meanwhile committed a fix to CVS, but that was a day 
after the official relase for 6.0. If you check out the newest stable 
branch from CVS (or ask me to send you diffs tomorrow), it should > work.
(That last commit made GHC quote all arguments it passes on to GHC; 
for Mac OS X, it passed "-framework HaskellSupport" instead of 
"-framework" "HaskellSupport". GCC doesn't report an error but it just 
ignores the former. Strange.)

I'll check it out from the CVS in the morning.


The "HaskellSupport" framework (which is not used if it's not detected 
at configure time; there should really be a configure switch for that) 
is just an aggregation of libgmp and libdl packaged as a framework. I 
figured that would be easier for end users of Haskell programs, as 
libgmp is required for all Haskell programs, and libdl is used by the 
Posix library (and how do you install a dylib using the Finder?). For 
something like darwinports, it might be better to just rely on the gmp 
and dl libraries installed with darwinports, but that makes programs 
compiled using ghc dependent on darwinports, too.

For darwinports, I'll probably just install gmp and dl as dependencies. 
There is
also provision to install frameworks in $prefix/Frameworks. I'll have 
to think about
which is more appropriate.

And you just reminded me that I still haven't uploaded the 10 line 
shell script for creating the HaskellSupport.framework anywhere, 
because I could never figure out the appropriate place in CVS:

#!/bin/sh
cd dlcompat-20020413
cp dlfcn.o ../
make
cd ../gmp-4.0.1
./configure
make
ld -r -d ./libs/libgmp.a -o ../libgmp.o
cd ..
ld -dylib -o HaskellSupport.framework/Versions/A/HaskellSupport 
libgmp.o dlfcn.o /usr/lib/dylib1.o -lSystem

OK, that's all for now...

Cheers,

	Wolfgang


Thanks for the help!

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: threaded-rts

[Gregory Wright]

On Wednesday, July 23, 2003, at 05:43 AM, Wolfgang Thaller wrote:
Well, let's see. I got my Powerbook back from repairs yesterday; now I 
have to track down one Mac-specific issue for 6.0.1. Then I'll have a 
look at the head and my old bound-threads prototypes. I might have 
some (preliminary, experimental, hackish, untested, ugly) patches 
ready on the weekend.

Cheers,

Wolfgang

Hi Wolfgang,

I built the cvs version of 6.0.1 on Sunday (the 20th of July) and had 
the linker problem mentioned
by Axel Simon (symbol _Main_zdmain_closure undefined). The build 
platform was OS X 10.2.6.

If this isn't the OS X bug you're working on let me know. I should have 
a chance to look into it
more deeply over the weekend.

Otherwise, send a note when you have something you would like tested. 
I'm getting much better
at building the ghc on my powerbook. ;-)

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC 6.0.1 build on Mac OS X

[Gregory Wright]

Hi Wolfgang,

I had a good compile of 6.0.1 from Thursday's cvs on Mac OS X 10.2.6.
I did a stage 2 build using your 6.0 package, then installed 6.0.1 and
rebuilt everything. I ran but a few test programs (mostly some 
networking
stuff I've been playing with); superficially it all works.

A minor issue: ghc advertises itself as version 6.1, ghci as 6.0.1. 
Which is
correct?

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 6.0.1 build on Mac OS X

[Gregory Wright]

When you say "6.01" from cvs, you are probably referring to the STABLE 
branch of the CVS. The stable branch will be released as "GHC 6.0.1" 
in a few days.
My copy reports 6.0.1 throughout, where does it say 6.1?

On the other hand, the HEAD branch of the CVS will be released as GHC 
6.2 in a few months (?); in the meantime, it should advertise itself 
as GHC 6.1.

This all makes sense now---I had built an earlier version off the HEAD, 
and another off the 6_0
branch. Both worked OK.

The case of my powerbook is running at 35 C all of the time from all 
the building it's doing.

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC 6.0.1 for Mac OS X available through darwinports

[Gregory Wright]

Hello,

GHC 6.0.1 for Mac OS X is now available through the darwinports system.

Darwinports is similar to the *BSD port system. It downloads and builds 
both
the target and dependencies automatically for your machine.

Note that darwinports is still under development. OS X users who want a 
simple,
reliable installation should use Wolfgang Thaller's GHC disk image. The 
darwinports
version is aimed at people who want to build from source. If you have 
suggestions
for particular customizations, let me know. Darwinports has support for 
'variant'
builds that make customization easy.

For more information on darwinports, and to download the 
infrastructure, see

http://www.opendarwin.org/projects/darwinports/

Best Wishes,

Greg Wright

Gregory Wright
Antiope Associates
18 Clay Street
Fair Haven, New Jersey 07704
USA
[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-6.0.1 on Mac OS X 10.3 (Panther)

[Gregory Wright]

Hi Wolfgang,

I just updated my powerbook to Panther and tried my old ghci image 
(built under Jaguar).
It seems to run OK, although I haven't tested it extensively. I used it 
with both
the terminal interface and emacs.

It may be possible to compile a Panther compiler using a ghc built 
under Jaguar;
I'll test this if I don't run into other issues in the next few days.

Best Wishes,
Greg Wright
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-6.0.1 on OS X Panther build

[Gregory Wright]

Hi Wolfgang,

I tried building 6.0.1 on Panther using 6.0.1 built on Jaguar. (The  
build was run under
darwinports.) It failed with the following:


==fptools== make all -r;
 in  
/Users/gwright/src/darwinports/dports/lang/ghc/work/ghc-6.0.1/ 
libraries/base

rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir  
GHC/Base_split; else /usr/bin/find GHC/Base_split -name '*.o' -print |  
xargs rm -f __rm_food; fi;
../../ghc/compiler/ghc-inplace -H16m -O -I/opt/local/include  
-L/opt/local/lib -pgmP "gcc3 -E -traditional" -fglasgow-exts -cpp  
-Iinclude -#include HsBase.h -funbox-strict-fields -package-name base  
-O -Rghc-timing  -split-objs-c GHC/Base.lhs -o GHC/Base.o  -ohi  
GHC/Base.hi
/tmp/ghc3798.split__111.s:unknown:missing indirect symbols for section  
(__DATA,__nl_symbol_ptr)
<>
make[2]: *** [GHC/Base.o] Error 1
make[1]: *** [all] Error 1
make: *** [build] Error 1

Warning: the following items did not execute (for ghc): com.apple.build
>


Ever see anything like this before?

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Building GHC on Mac OS X or Fixing readline

[Gregory Wright]

Hi Kennis,

I've just made the GHC-6.0.1 port under darwinports work, so I know  
what the problem is.
(Actually, I know what the problem is because Wolfgang told me :-) )

You're using gcc-3.3 and need to either compile HEAD from cvs or force  
the build to
use gcc-3.1. Try running configure as

	./configure --with-gcc=gcc3 --with-ghc='ghc -pgmP "gcc3 -E  
-traditional"'

You may also need to add a one line mk/build.mk containing:

	SRC_HC_OPTS += -pgmP "gcc3 -E -traditional"

The problem you are having is the gcc-3.3 preprocessor is fussier than  
that of 3.1.

(I had looked at applying Wolfgang's patches piecemeal to 6.0.1 but  
after several
almost-but-not-quite builds decided to just take the simple route.)

 Regarding the second problem, whose dlcompat library are you using?

Note that if you just want to build ghc from scratch, you can download  
the
darwinports system from opendarwin.org/projects/darwinports. Install it  
and
then cd to the directory lang/ghc. Type sudo port -dv install and you  
will install
ghc, along with compatible versions of dlcompat, gmp and readline.
(Or you can just peek at the Portfile and files/patch-* to see what I  
had to do
to get the build to work.)

The only downside of the darwinports build of ghc is that it puts some  
libraries
in /lib, which not on the usual system library  
path. This requires
adding -L/lib explicitly to your invocations of  
ghc. This can
be fix, but I haven't bothered to do it yet.

Best WIshes,

Greg

On Oct 30, 2003, at 11:47 PM, Kennis Koldewyn wrote:

I've attempted to compile GHC 6.01 from sources for Mac OS X, but  
after a successful configure, make soon grinds to a halt (see "Listing  
1" below).  I'm looking for either:

1.  A brief list of tips and tricks for getting GHC to build on Mac OS  
X (see "My Mac" below), or

2.  A way to fix my broken readline package (see "Listing 2" below).   
Arthur Baars mentioned on 2003-07-18 (see "Message Link 1" below) that  
this problem had been fixed in 6.0.1, and the GHC Downloads page  
mentions that the readline library must be installed.  I've installed  
GHC 6.0.1 using Wolfgang Thaller's Mac OS X package and I  
(subsequently) installed readline 4.3, but GHCi still panics, and I  
also tried Arthur's "quick fix" without success.

Thanks for any helpful suggestions,

- Kennis

- Kennis Koldewyn ([EMAIL PROTECTED]) -
Without computers, it would be virtually impossible
for us to accompliowur xow;gkc,mf(&(   - Dave Barry
- Start of Listing 1 -
==fptools== make boot - --no-print-directory -r;
 in /Users/kennis/Downloads/ghc-6.0.1/ghc/utils/ghc-pkg
--- 
-
/usr/local/bin/ghc -M -optdep-f -optdep.depend  -osuf o-H16m -O  
-cpp -DPKG_TOOL -DWANT_PRETTY Main.hs Package.hs ParsePkgConfLite.hs
make all
/usr/local/bin/ghc -H16m -O -cpp -DPKG_TOOL -DWANT_PRETTY-c  
Package.hs -o Package.o  -ohi Package.hi
Package.hs:1: parse error on input `#'
make[4]: *** [Package.o] Error 1
make[3]: *** [boot] Error 2
make[2]: *** [boot] Error 1
make[1]: *** [boot] Error 1
make: *** [build] Error 1
- End of Listing 1 -

- Start of My Mac -
I'm running Mac OS 10.2.8 on an 800 MHz PowerPC G3 12" iBook with 384  
MB of memory:

[/Users/kennis] uname -a
Darwin Voxel.local. 6.8 Darwin Kernel Version 6.8: Wed Sep 10 15:20:55  
PDT 2003; root:xnu/xnu-344.49.obj~2/RELEASE_PPC  Power Macintosh  
powerpc
[/Users/kennis] gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1493)
- End of My Mac -

- Start of Listing 2 -
[/Users/kennis] ghci -package util
   ___ ___ _
  / _ \ /\  /\/ __(_)
 / /_\// /_/ / /  | |  GHC Interactive, version 6.0.1, for Haskell  
98.
/ /_\\/ __  / /___| |  http://www.haskell.org/ghc/
\/\/ /_/\/|_|  Type :? for help.

Loading package base ... linking ... done.
Loading package lang ... linking ... done.
Loading package concurrent ... linking ... done.
Loading package readline ... linking ...
/usr/local/lib/ghc-6.0.1/HSreadline.o: unknown symbol  
`_rl_free_undo_list'
ghc-6.0.1: panic! (the `impossible' happened, GHC version 6.0.1):
can't load package `readline'
- End of Listing 2 -

- Message Link 1 -
http://www.mail-archive.com/[EMAIL PROTECTED]/ 
msg05041.html
- End Message Link 1 -

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Building GHC on Mac OS X or Fixing readline

[Gregory Wright]

On Oct 31, 2003, at 2:15 PM, Kennis Koldewyn wrote:

On Friday, Oct 31, 2003, at 08:56, Gregory Wright wrote:
I've just made the GHC-6.0.1 port under darwinports work, so I know 
what the problem is.
(Actually, I know what the problem is because Wolfgang told me :-) )

You're using gcc-3.3 and need to either compile HEAD from cvs or 
force the build to
use gcc-3.1. Try running configure as

	./configure --with-gcc=gcc3 --with-ghc='ghc -pgmP "gcc3 -E 
-traditional"'
Well, it's been cranking along now for four or five hours, and is 
still compiling away, so that seems to be working.

Yes, it does take a long time---about 5 hours on my powerbook G4 800 
MHz.

Regarding the second problem, whose dlcompat library are you using?
[/Users/kennis/] cd 
/Library/Receipts/dlcompat-10505X.pkg/Contents/Resources/
[...505X.pkg/Contents/Resources] cat dlcompat-10505X.info
Title dlcompat
Version 20010505
...

What would I need to do if I got a more recent version (say 2003-06-29 
from opendarwin.org)?

The problem with dlcompat is probably not the version, but that there 
are two different conventions
regarding stripping leading underscores. GHC uses the 'fink' style 
convention, not the
opendarwin convention. This will just drive you nuts. The best thing to 
do is to update
ghc/rts/Linker.c. Look at the version in the cvs, and look where dlsym 
is called. Wolfgang
has modified it in HEAD to use the native OS X dynamic symbol lookup 
procedure. Change
just those few lines, otherwise you'll have to do more extensive 
upgrading to get the build
to work again.

Before you go to all this trouble, you might want to rebuild dlcompat 
with debugging
turned on. If the symbol dlcompat says it is trying to find differs by 
an underscore from
the one that GHCi complains about, you know the problem is there.

Greg


Thanks for your help,

- Kennis

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Announce: GHC 6.2 for Mac OS X Jaguar and Panther

[Gregory Wright]

Hello,

A port of ghc-6.2 for Mac OS X (both Jaguar and Panther) is available 
from the
darwinports system.

Information on obtaining darwinports is available from 
http://darwinports.opendarwin.org.

Once darwinports is installed, building ghc is done by changing to the
lang/ghc directory and issuing the command:
	sudo port install

ghc will be built from source and by default is installed in 
/opt/local/bin, although the
user may specify another installation directory.

This release supports building with HOpenGL support. It is not included 
by default,
but may be specified by the command:

	sudo port install +opengl

Note that as the system is built from source it may take several hours 
for the
'port install' command to finish. (On an 800 MHz G4 powerbook it takes 
about
four and a half hours.)

ghc from darwinports may be helpful for those still using Jaguar and 
are having
difficulty with Wolfgang Thaller's binary distribution for Panther. Or 
you may just
like building from source, like me.

Best Wishes,
Greg Wright
Gregory Wright
Antiope Associates LLC
18 Clay Street
Fair Haven, New Jersey 07704
[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC-6.2 and Template Haskell on OS X

[Gregory Wright]

Hi,

I have a question about ghc-6.2 and template haskell on  Mac OS X. I 
think
it's a ghc configuration or build issue, so I'm posting here instead of 
the TH list.

I have ghc-6.2 built under darwinports. This uses a 6.0.1 binary to 
bootstrap the
6.2 build. I haven't updated the binary bootstrap compiler because it 
seems
to work under both Jaguar (10.2.x) and Panther (10.3.x). The portfile 
builds ghc-6.2
with the command 'make all'. The resulting ghc-6.2 has worked fine 
until I tried to
build a program using TH. I tried to build the simplest example--the 
one in the
User's guide-- and it failed with:

> ghc --make -fth main.hs -o main
Chasing modules from: main.hs
Compiling Printf   ( ./Printf.hs, ./Printf.o )
./Printf.hs:23: Type constructor or class not in scope: `Expr'

./Printf.hs:26: Variable not in scope: `string'

./Printf.hs:30: Type constructor or class not in scope: `Expr'
>
This must be a simple problem. The other thing to note about the 
darwinports
build is that it stages the installation into a temporary directory so 
it can do an
inventory of the files that will be installed. If a path in the staging 
directory gets
compiled in, instead of the final installation directory, all manner of 
unhappiness
can result.

Any one have any ideas? The answer is probably staring me in the face 
but
I'm not able to see it.

Best Wishes,

Greg

Gregory Wright
Antiope Associates LLC
18 Clay Street
Fair Haven, New Jersey 07704
[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC 6.2.1 under darwinports

[Gregory Wright]

Hi,

The Glasgow Haskell Compiler supported under darwinports has been
bumped to version 6.2.1. By default, GHC now builds with OpenGL support.
The build should work for both OS X 10.2.x and 10.3.x.
This lets Mac OS X jaguar users to get the latest version
of GHC, as Wolfgang Thaller's binary release is only tested with 
panther.
It can also provide amusement for those who just like to build from 
source.

For information on getting darwinports, see 
http://darwinports.opendarwin.org.

Best Wishes,
Greg Wright
Gregory Wright
Antiope Associates LLC
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Announcement: GHC 6.2.1 under darwinports

[Gregory Wright]

Hi,

The Glasgow Haskell Compiler supported under darwinports has been
bumped to version 6.2.1. By default, GHC now builds with OpenGL support.
The build should work for both OS X 10.2.x and 10.3.x.
This lets Mac OS X jaguar users to get the latest version
of GHC, as Wolfgang Thaller's binary release is only tested with 
panther.
It can also provide amusement for those who just like to build from 
source.

For information on getting darwinports, see 
http://darwinports.opendarwin.org.

Best Wishes,
Greg Wright
Gregory Wright
Antiope Associates LLC
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

type checker tree output

[Gregory Wright]

Hi,

Is there any way to make GHC dump the type checker tree in some kind of
human readable format? I'm not interested in it when it is successful, 
but I'd
like to look at the search tree when type checking fails.

Is this possible?

Best Wishes,
Greg Wright
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Dynamic loading problem

[Gregory Wright]

Hi,

I was playing with dynamically loaded modules and had the same problem.
It has nothing to do with shared objects. What you have to do is to 
force
the main program (the one that loads the loadable modules) to explicitly
link all of the object files that the set {, }
depends on.

For example, if a module depends on symbols in 
/HShaskell98.o,
(but the main program doesn't), you should explicit link 
/HShaskell98.o
into the main program.

This happens because when you build your loadable modules the linker
assumes that they will later be linked into a main program, at which 
time
all of the undefined references will be resolved. Since you never link 
the modules
and main together, some references remain unresolved.

It shouldn't be hard to automate this; a script could run nm on the 
module
and main program, make a list of unresolved references, search the files
in  to know which object to include, and then relink the 
main
program.

If you look at the makefiles in

http://www.algorithm.com.au/wiki/hacking/haskell.ghc_runtime_loading

you'll see some examples of how the main program has to be linked.

Best Wishes,
Greg


On Apr 29, 2004, at 3:24 PM, Hampus Ram wrote:

On Thu, Apr 29 2004, Alastair Reid wrote:
Does passing the flag RTLD_GLOBAL to dlopen help?  (man dlopen for 
info about
this flag)
No, since none of the objects involved are shared objects (I use 
neither
dlopen or addDLL but the loadObj function). They are just compiled 
Haskell
modules and the problem lies in the RTS symbols which for some reason 
can't
be loaded dynamically (why it doesn't work when the base package etc. 
can
be loaded is beyond me).

However when loading shared objects your flag is the one to use. That
works without flaw and is really a nicer way to load shared objects 
than
the RTS function addDLL.

/Hampus

--
Homepage: http://www.dtek.chalmers.se/~d00ram
E-mail: [EMAIL PROTECTED]
"Det är aldrig försent att ge upp"
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ghc-devel for darwinports

[Gregory Wright]

Hi,
Due to overwhelming popular demand (well, Sven asked), darwinports
now includes a port 'lang/ghc-devel', which builds from the head of the 
cvs.
The default build includes support for openGL, so this is a way to get
the latest OpenGL support for ghc, which now supports almost all of 
version 1.5.

The ghc-devel port installs as ghc-6.3. (All of the executables have 
the "-6.3"
suffix, so you can install ghc and ghc-devel without conflict. You 
invoke the
new compiler as ghc-6.3 and the interactive environment as ghci-6.3.)

ghc-devel depends on ghc, alex and happy, so if you have none of these
installed and say
sudo port install ghc-devel
you'll get a full bootstrap build of the released version of ghc, along 
with
builds of alex and happy (the lexer and parser generators, 
respectively),
followed by a build of ghc from cvs. This may take some time (about 10 
hours
on an 800 MHz G4), but what would you rather have your CPU doing?

Best Wishes,
Greg
Gregory Wright
Antiope Associates LLC
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghc-devel for darwinports

[Gregory Wright]

This is a good idea.  Maybe the infrastructure can support a haskell
directory under lang/ where all of the haskell ports could reside.
The existing arrangement is modeled on FreeBSD's port layout,
which is a relatively flat hierarchy. This, I think, was caused by
the limitations of using makefiles. Darwinports is driven by tcl
scripts so in principle there is no reason not to organize the port
tree as a deeper hierarchy.
This would especially help the perl/python/gtk maintainers, as the
number of supported versions grows.
BTW, sometime soon I'll put together a haskell toolkit meta-port,
which will build ghc, alex, haddock, buddha, c2hs, hat
and anything else that people want. The idea is to have a consistent
set of versions, so you can start a build in the evening and have
a consistent, working ghc development environment ready
to use by the time you enjoy a cup of coffee the next morning.
Greg
On May 20, 2004, at 5:22 PM, David Leimbach wrote:
Do we have enough Haskell now for it to have it's own category?
Python and other languages have their own category and it makes
it easier for folks like me to "browse the haskell library" of 
darwinports.

That is unless we can get some kind of decent query system in 
Darwinports
for finding out what's available.  I think a good enough query system 
would
make most categories somewhat superfluous.

dave
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.2.2

[Gregory Wright]

Hi,
For Mac OS X users, the Darwinports build of GHC has been updated
to the new version (6.2.2). It supports both Jaguar (10.2.x) and
Panther (10.3.y). Apple's gcc-3.1 is required, which is not installed
by default with the latest Xcode 1.5. (Use the "custom installation"
option of the Xcode installer to install gcc-3.1.) This restriction will
be lifted in the future.
The build is from source, using a binary bootstrap compiler (6.0.1).
It takes about five hours on an 800 MHz G4 PowerBook.
For more information on installing and using Darwinports, see
http://darwinports.opendarwin.org. Many haskell utilities (e.g.,
alex, darcs, happy, haddock, hs-plugins, hsshellscript) are available
through Darwinports.
Best Wishes,
Greg Wright
Gregory Wright
Antiope Associates
[EMAIL PROTECTED]
On Oct 15, 2004, at 10:25 AM, Simon Marlow wrote:
   =
The (Interactive) Glasgow Haskell Compiler -- version 6.2.2
   =
The GHC Team is pleased to announce the latest patchlevel release of
GHC, 6.2.2.  This is a bugfix release only, there are no new features.
Code that worked with 6.2.1 will work unchanged with 6.2.2.
A lot of bugfixes have gone into 6.2.2; we believe it is one of the
most stable releases of GHC ever.  Thanks to everyone who has been
involved in testing pre-releases and submitting bug reports.
This will also be the last release along the 6.2 branch, the next
release (out "soon") will be 6.4 with plenty of new features.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] Re: ANNOUNCE: GHC version 6.2.2

[Gregory Wright]

Hi Tom,
If this isn't just running out of disk space, let me know your hardware 
configuration
and Xcode versions (uname -a, processor type and total amount of 
memory, gcc3 -v).

So far, all of the reported problems building 6.2.2 under darwinports 
have been related
to Apple's gcc3 (i.e., gcc-3.1) not being installed by default under 
Xcode 1.5.

Best Wishes,
Greg
On Oct 20, 2004, at 10:32 AM, Tom Davie wrote:
The darwin ports version appears not to be too happy just now...
Error: Target com.apple.build returned: shell command "cd
"/Users/tatd2/darwinports/dports/lang/ghc/work/ghc-6.2.2" && make all"
returned error 2
Command output:  In the definition of `remInteger':
 remInteger (S# a) (S# b) = ...
 remInteger (ia@(S# _)) (ib@(J# _ _)) = ...
 remInteger (J# sa a) (S# b) = ...
 remInteger (J# sa a) (J# sb b) = ...
GHC/Num.lhs:181:
Warning: Pattern match(es) are overlapped
 In the definition of `quotInteger':
 quotInteger (S# a) (S# b) = ...
 quotInteger (ia@(S# _)) (ib@(J# _ _)) = ...
 quotInteger (J# sa a) (S# b) = ...
 quotInteger (J# sa a) (J# sb b) = ...
<>
(cd GHC/ && /usr/bin/ld -r -x -o Num.o Num_split/*.o);
rm -f GHC/ST.o; if [ ! -d GHC/ST_split ]; then mkdir GHC/ST_split;
else /usr/bin/find GHC/ST_split -name '*.o' -print | xargs rm -f
__rm_food; fi;
../../ghc/compiler/ghc-inplace -H16m -O -I/opt/local/include
-L/opt/local/lib -pgmP "gcc3 -E -traditional" -fglasgow-exts -cpp
-Iinclude -#include HsBase.h -funbox-strict-fields -package-name base
-O -Rghc-timing  -split-objs-c GHC/ST.lhs -o GHC/ST.o  -ohi
GHC/ST.hi
<>
(cd GHC/ && /usr/bin/ld -r -x -o ST.o ST_split/*.o);
rm -f GHC/Arr.o; if [ ! -d GHC/Arr_split ]; then mkdir GHC/Arr_split;
else /usr/bin/find GHC/Arr_split -name '*.o' -print | xargs rm -f
__rm_food; fi;
../../ghc/compiler/ghc-inplace -H16m -O -I/opt/local/include
-L/opt/local/lib -pgmP "gcc3 -E -traditional" -fglasgow-exts -cpp
-Iinclude -#include HsBase.h -funbox-strict-fields -package-name base
-O -Rghc-timing  -split-objs-c GHC/Arr.lhs -o GHC/Arr.o  -ohi
GHC/Arr.hi
<>
(cd GHC/ && /usr/bin/ld -r -x -o Arr.o Arr_split/*.o);
rm -f GHC/Real.o; if [ ! -d GHC/Real_split ]; then mkdir
GHC/Real_split; else /usr/bin/find GHC/Real_split -name '*.o' -print |
xargs rm -f __rm_food; fi;
../../ghc/compiler/ghc-inplace -H16m -O -I/opt/local/include
-L/opt/local/lib -pgmP "gcc3 -E -traditional" -fglasgow-exts -cpp
-Iinclude -#include HsBase.h -funbox-strict-fields -package-name base
-O -Rghc-timing  -split-objs-c GHC/Real.lhs -o GHC/Real.o  -ohi
GHC/Real.hi
/var/tmp//ccjMNPay.s: No space left on device
<>
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Change in ghc-6.2.2 distribution files

[Gregory Wright]

Hi,
Did the file ghc-6.2.2.tar.bz2 get changed without the version number 
being
changed? The md5 sum of the files has changed, breaking the darwinports
and presumably the *BSD ports builds as well.

I didn't see any notice to the list, so I'm not sure if the change is 
intentional,
or if the wrong file is being distributed.

Best Wishes,
Greg
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Change in ghc-6.2.2 distribution files

[Gregory Wright]

Hi Sven,
Yes, that would be it. The change is harmless enough.
Thanks for the pointer to the message.
Greg
On Oct 23, 2004, at 3:01 PM, Sven Panne wrote:
Gregory Wright wrote:
Did the file ghc-6.2.2.tar.bz2 get changed without the version number 
being
changed? The md5 sum of the files has changed, breaking the 
darwinports
and presumably the *BSD ports builds as well.
I didn't see any notice to the list, so I'm not sure if the change is 
intentional, or if the wrong file is being distributed.
Hmmm, I guess it's this:
   http://www.haskell.org//pipermail/cvs-ghc/2004-October/022173.html
Cheers,
   S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHC version 6.2.2 on MacOS X via darwinports

[Gregory Wright]

Hi,
GHC-6.2.2 can now be built from source on Mac OS X using the
darwinports systems with the default gcc. Previously, gcc-3.1 was
required. Now gcc-3.3 is used when building on Panther (10.3.x)
and gcc-3.1 is only required for builds on Jaguar (10.2.y). This should
make life simpler for users of Panther and may even work for
people with prerelease versions of Tiger.
Thanks to Wolfgang Thaller for making the Mac OS X port of ghc-6.2.2
build with the default compiler, and to John Peterson (haskell.org)
and Felix Kronlage (opendarwin.org) for help with hosting the new
bootstrap compiler.
Best Wishes,
Greg
Gregory Wright
Antiope Associates LLC
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Updates for Mac OS X users using Darwinports

[Gregory Wright]

Hi,
Users of Mac OS X/Darwinports will find new portfiles for
ghc (ghc-6.4),
nhc98 (nhc-1.18) and
hugs98 (March 2005 release).
The hmake port has been bumped to version 3.10 and a new
port of cpphs (version 0.9) has been added.
The darwinports system builds from source, although progress
is being made on extending it to provide binary packages as well.
A new ghc-devel port will be available soon for those who want to
live on the bleeding edge.
Thanks to Malcolm Wallace for ironing out some last minute issues
with nhc98.
Best Wishes,
Greg
Gregory Wright
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users