Re: progress on Freebsd-amd64 (Was: .hc files for building ghc-6.4.1 on amd64 ?)

2005-09-22 Thread Tomasz Zielonka
On 9/21/05, Wilhelm B. Kloke [EMAIL PROTECTED] wrote:
Now I have an unregisterised ghc-inplace. What is the fastest way to testits usability?
Great! Could you put it somewhere on the web?
I have FreeBSD 5.4 here, and you?

Best regards
Tomasz

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


RE: .hc files for building ghc-6.4.1 on amd64 ?

2005-09-21 Thread Simon Marlow
On 20 September 2005 12:24, Wilhelm B. Kloke wrote:

 Deletion of Linker.c and manual build of some AutoApply files make
 the crossbuild work on i386 side. I have a copy of the
 resulting hc-bundle ready. If anybody wants them, send me a mail.
 They don't work on the amd64 side, though. Here is the error message:
 
 gcc -x c GHC/Int.hc -o GHC/Int.o -c -O  -DNO_REGS
 -DUSE_MINIINTERPRETER  -D__GLASGOW_HASKELL__=604  -O
 -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes
 -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include
 -I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include

-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include

-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/inclu
de
 -I.  `echo  | sed 's/^$/-DSTOLEN_X86_REGS=4/'` GHC/Int.hc: In
 function `s83O_ret':   
 GHC/Int.hc:2522: error: `int64ToIntegerzh_fast' undeclared (first use
 in this function) 
 GHC/Int.hc:2522: error: (Each undeclared identifier is reported only
 once 
 GHC/Int.hc:2522: error: for each function it appears in.)
 GHC/Int.hc: In function `s83J_ret':
 GHC/Int.hc:2583: error: `int64ToIntegerzh_fast' undeclared (first use
 in this function) 
 gmake[1]: *** [GHC/Int.o] Fehler 1
 gmake: *** [all] Fehler 1
 gmake: Leaving directory
 `/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries' 

I think this means that something has gone wrong during the generation
of the .hc files on the host machine.  GHC/Int.hc is not supposed to
refer to int64ToIntegerzh_fast, because on a 64-bit machine there is no
Int64# primitive type (it's the same as Int#).  You might want to make
sure that ghc/includes/ghcautoconf.h on the host machine is the right
one - it should have been copied from the target machine.

 I notices that the evil mangler was replaced after my build. I don't
 have 
 an idea whether this would make it work.
 
 BTW. FreeBSD-amd64 does not seem to support small memory model. Is
 this essential?

If that's true, it means the port is going to require more work.  But
I'd be surprised, because FreeBSD is using the same compiler toolchain
as everyone else.

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


progress on Freebsd-amd64 (Was: .hc files for building ghc-6.4.1 on amd64 ?)

2005-09-21 Thread Wilhelm B. Kloke
Simon Marlow [EMAIL PROTECTED] schrieb:

 Int64# primitive type (it's the same as Int#).  You might want to make
 sure that ghc/includes/ghcautoconf.h on the host machine is the right
 one - it should have been copied from the target machine.

Yes. ghcautoconf.h had been rebuilt accidentally.

Now I have an unregisterised ghc-inplace. What is the fastest way to test
its usability?

The next failure is at Control/Arrow.hc after reconfiguration in hc-build:

==fptools== gmake all -wr;
 in /data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base

gcc -x c Control/Arrow.hc -o Control/Arrow.raw_s -S -O   
-D__GLASGOW_HASKELL__=604  -O 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include  
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/include
-I.  `echo  | sed 's/^$/-DSTOLEN_X86_REGS=4/'`
Control/Arrow.hc: In function `s39r_entry':
Control/Arrow.hc:25: error: `stg_ap_p_ret' undeclared (first use in this 
function)
Control/Arrow.hc:25: error: (Each undeclared identifier is reported only once
Control/Arrow.hc:25: error: for each function it appears in.)
Control/Arrow.hc: In function `s39v_entry':
Control/Arrow.hc:46: error: `stg_ap_p_ret' undeclared (first use in this 
function)
...

-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

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


Re: .hc files for building ghc-6.4.1 on amd64 ?

2005-09-20 Thread Wilhelm B. Kloke
Wilhelm B. Kloke [EMAIL PROTECTED] schrieb:
 Simon Marlow [EMAIL PROTECTED] schrieb:
 On 17 September 2005 22:05, Wilhelm B. Kloke wrote:

 I tried to go back to ghc/rts to build more files following the
 ipattern of the last steps before, but this destroys genapply.

 Don't quite understand this - could you elaborate?

 I tried
 (cd ghc/rts ; gmake all)
 after (cd ghc/compiler ; gmake stage=2 )

Small, but possibly essential, correction:
after completion of the whole other stuff.

 I have further information now. When compiling Linker.c,
 the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64.
 Perhaps just removing this could make it work. I have no idea
 why it is needed on linux-x86_64.

Deletion of Linker.c and manual build of some AutoApply files make
the crossbuild work on i386 side. I have a copy of the
resulting hc-bundle ready. If anybody wants them, send me a mail.
They don't work on the amd64 side, though. Here is the error message:

gcc -x c GHC/Int.hc -o GHC/Int.o -c -O  -DNO_REGS -DUSE_MINIINTERPRETER  
-D__GLASGOW_HASKELL__=604  -O 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/ghc/includes 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/base/include 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/unix/include 
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/parsec/include  
-I/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries/readline/include
-I.  `echo  | sed 's/^$/-DSTOLEN_X86_REGS=4/'`
GHC/Int.hc: In function `s83O_ret':
GHC/Int.hc:2522: error: `int64ToIntegerzh_fast' undeclared (first use in this 
function)
GHC/Int.hc:2522: error: (Each undeclared identifier is reported only once
GHC/Int.hc:2522: error: for each function it appears in.)
GHC/Int.hc: In function `s83J_ret':
GHC/Int.hc:2583: error: `int64ToIntegerzh_fast' undeclared (first use in this 
function)
gmake[1]: *** [GHC/Int.o] Fehler 1
gmake: *** [all] Fehler 1
gmake: Leaving directory 
`/data/home/wb/Haskell/fptools-amd64/ghc-6.4.1/libraries'

I notices that the evil mangler was replaced after my build. I don't have
an idea whether this would make it work.

BTW. FreeBSD-amd64 does not seem to support small memory model. Is this
essential?
-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

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


RE: .hc files for building ghc-6.4.1 on amd64 ?

2005-09-19 Thread Simon Marlow
On 17 September 2005 22:05, Wilhelm B. Kloke wrote:

 I tried it again today. One of my problems was related to gmake
 version. 
 The configure script should warn, if gmake is older than 3.80 (I had
 3.78). 

I'm using 3.79.1.  I do vaguely remember a problem with older versions
of gmake - what goes wrong for you?

 The building of the .hc bundle fails wirth the following messages:
 
 ...
 tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat
 hc-files-to-go` 
 tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or
 directory 
 tar: ghc-6.4.1/ghc/rts/StgStartup.hc: Cannot stat: No such file or
 directory 
 tar: ghc-6.4.1/ghc/rts/StgStdThunks.hc: Cannot stat: No such file or
 directory 
 tar: ghc-6.4.1/ghc/rts/Updates.hc: Cannot stat: No such file or
 directory 
 tar: ghc-6.4.1/ghc/rts/Apply.hc: Cannot stat: No such file or
 directory 
 tar: ghc-6.4.1/ghc/rts/Exception.hc: Cannot stat: No such file or
 directory 
 tar: ghc-6.4.1/ghc/rts/HeapStackCheck.hc: Cannot stat: No such file
 or directory 
 tar: ghc-6.4.1/ghc/rts/StgMiscClosures.hc: Cannot stat: No such file
 or directory 
 tar: ghc-6.4.1/libraries/haskell-src/Language/Haskell/Parser.hs:
 Cannot stat: No such file or directory gmake: *** [hc-file-bundle]
 Fehler 1 

Yes, you do actually need to generate these .hc files on the host
system.  What happened to the build in ghc/rts - could you post the
error message?  Possibly a 'make -k' in ghc/rts will be enough to get
these files.

 I tried to go back to ghc/rts to build more files following the
 ipattern of the last steps before, but this destroys genapply.

Don't quite understand this - could you elaborate?

 Further, there are some hsc.c files of length 0 like:
 ~/Haskell/fptools-i386amd64/ghc-6.4.1 0$ ls -l
 libraries/base/System/*hsc.c 
 -rw-r--r--  1 wb  ifado  0 17 Sep 21:31
 libraries/base/System/CPUTime_hsc.c 
 -rw-r--r--  1 wb  ifado  0 17 Sep 21:31
 libraries/base/System/Time_hsc.c 

This is correct (the C compiler should generate an empty object file
when compiling them).  It was easier to avoid the special case in the
build system when the _hsc.c file is empty.
 
 The building process on the target system fails with messages that
 there is no rule to build those files. Also, I needed to have happy
 and alex 
 on the target system, because make boot fails without them (catch 22).

When things are working properly, you don't need Happy or Alex on the
target system.  I suspect things have gone wrong earlier.

 A final glitch is that (at least, my) FreeBSD-amd64-6.0 gcc does not
 include -I/usr/local/include and -L/usr/local/lib in the search path.
 So libgmp is not found.

Ok.  You can use the libgmp in the tree (this should happen
automatically), or you can add the -I/-L flags to the relevant places.
This is something we don't handle very well right now, though.

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


Re: .hc files for building ghc-6.4.1 on amd64 ?

2005-09-19 Thread Wilhelm B. Kloke
Simon Marlow [EMAIL PROTECTED] schrieb:
 On 17 September 2005 22:05, Wilhelm B. Kloke wrote:

 I tried it again today. One of my problems was related to gmake
 version. 
 The configure script should warn, if gmake is older than 3.80 (I had
 3.78). 

 I'm using 3.79.1.  I do vaguely remember a problem with older versions
 of gmake - what goes wrong for you?

The old gmake does not get the dependencies right.

 The building of the .hc bundle fails wirth the following messages:
 
 ...
 tar czf ghc-6.4.1-x86_64-unknown-freebsd-hc.tar.gz `cat
 hc-files-to-go` 
 tar: ghc-6.4.1/ghc/rts/PrimOps.hc: Cannot stat: No such file or
 directory 
...
 Cannot stat: No such file or directory gmake: *** [hc-file-bundle]
 Fehler 1 

 Yes, you do actually need to generate these .hc files on the host
 system.  What happened to the build in ghc/rts - could you post the
 error message?  Possibly a 'make -k' in ghc/rts will be enough to get
 these files.

 I tried to go back to ghc/rts to build more files following the
 ipattern of the last steps before, but this destroys genapply.

 Don't quite understand this - could you elaborate?

I tried
 (cd ghc/rts ; gmake all)
after (cd ghc/compiler ; gmake stage=2 )

I have further information now. When compiling Linker.c,
the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64.
Perhaps just removing this could make it work. I have no idea
why it is needed on linux-x86_64.

 there is no rule to build those files. Also, I needed to have happy
 and alex 
 on the target system, because make boot fails without them (catch 22).

 When things are working properly, you don't need Happy or Alex on the
 target system.  I suspect things have gone wrong earlier.

Probably. But this is in a very early stage. It even happens when using
 gmake -n boot
(for finding the cause I wanted to know the commands which may have failed),
that two command using $(HAPPY) and $(ALEX) are executed. I was not
able to locate the point better. Perhaps you could try the first stages of
the crossbuild on suitable system, where these two variable from
mk/config.mk are defined empty (as was the case on my system after configure).

 A final glitch is that (at least, my) FreeBSD-amd64-6.0 gcc does not
 include -I/usr/local/include and -L/usr/local/lib in the search path.
 So libgmp is not found.

 Ok.  You can use the libgmp in the tree (this should happen
 automatically), or you can add the -I/-L flags to the relevant places.

This was not possible, as x86_64 does not seem supported in ghc's gmp.
The other solution (exporting LDFLAGS=-L/usr/local/lib) works.

-- 
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257

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


RE: .hc files for building ghc-6.4.1 on amd64 ?

2005-09-19 Thread Simon Marlow
On 19 September 2005 12:45, Wilhelm B. Kloke wrote:

 I tried
 (cd ghc/rts ; gmake all)
 after (cd ghc/compiler ; gmake stage=2 )

You should try a 'gmake -k' in ghc/rts, that might be enough to get the
required .hc files.
 
 I have further information now. When compiling Linker.c,
 the compilation fails, because there is no MAP_32BIT in FreeBSD-amd64.
 Perhaps just removing this could make it work. I have no idea
 why it is needed on linux-x86_64.

MAP_32BIT is quite important: it tells mmap() to return memory in the
lower 2Gb of the address space, so that we can assume all symbols have
32 bit addresses.  This is how the small memory model on Linux works.  I
bet FreeBSD has something equivalent (or maybe not?).

This is only required for GHCi.  You can get a working compiler without
needing a working Linker.c.

 Probably. But this is in a very early stage. It even happens when
 using 
 gmake -n boot
 (for finding the cause I wanted to know the commands which may have
 failed), that two command using $(HAPPY) and $(ALEX) are executed. I
 was not 
 able to locate the point better. Perhaps you could try the first
 stages of the crossbuild on suitable system, where these two variable
 from 
 mk/config.mk are defined empty (as was the case on my system after
 configure).

I would, but I'm kind of busy doing the 6.4.1 release right now.  When I
have more time, I plan to try the port to FreeBSD/amd64 myself (unless
anyone gets there first).

Cheers,
Simon

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