Re: Bootstrapping for Leopard
On Wednesday 30 January 2008 10:13:01 Manuel M T Chakravarty wrote: Upon inspection of the configure script, I found out that line 2651 uses the variable designating the ghc compiler. This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. It however messes everything up if you want to build from HC files (and so don't have a Haskell compiler). I am not sure whether anybody thought about this problem when the change to using Haskell scripts instead of shell scripts was made. Ian? Simon? The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. Dear Manuel, Your explanation makes perfect sense. For those more involved in the build process of GHC: How hard is it to roll back the vanilla shell scripts that once upon a time were used and to have 'configure' default to them when the --enable-hc-boot switch is used? Wrt. to the missing .hc files from rts/*.cmm: Since these weren't built in the make process, are they actually required? If not, it should simply be an extra test in the Makefile for the hc-file-bundle. Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping for Leopard
On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote: [Philip K.F. Hölzenspies:] make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name *.cmm -follow -print` ; do \ if test x$$f !=3D x; then \ echo `echo $$f | sed 's/cmm$$/hc/g' ` hc-files-to-go ; \ fi; \ done; This is strange. I've all kinds of trouble getting hc-bootstrapping back (for OpenBSD, but also in general), and I didn't see *that* problem. checking for path to top of build tree... ./configure: line 2651: - v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory [...] This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. But it just doesn't make sense at all. You need a good set of shell commands at all, since they're used by configure as well as in Makefiles. I really can't believe that simple stuff like this doesn't work on windos: --- aclocal.m4.orig Mon Dec 10 19:11:31 2007 +++ aclocal.m4 Sun Jan 20 17:10:07 2008 @@ -1098,20 +1098,14 @@ AC_REQUIRE([AC_PROG_CC]) AC_DEFUN([FP_FIND_ROOT],[ AC_MSG_CHECKING(for path to top of build tree) -dnl This would be -dnl make -C utils/pwd clean make -C utils/pwd -dnl except we don't want to have to know what make is called. Sigh. -if test ! -f utils/pwd/pwd test ! -f utils/pwd/pwd.exe; then - cd utils/pwd - rm -f *.o - rm -f *.hi - rm -f pwd - rm -f pwd.exe - $WithGhc -v0 --make pwd -o pwd - cd ../.. -fi - -hardtop=`utils/pwd/pwd forwardslash` +case $HostPlatform in +*cygwin32|*mingw32) + hardtop=`pwd | tr \\ /` + ;; +*) + hardtop=`pwd` + ;; +esac if ! test -d $hardtop; then AC_MSG_ERROR([cannot determine current directory]) ifBuildable.hs is similar; it can be replaced by a shell script or even done within libraries/Makefile using very basic shell commands. The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. How is ghc currently built on windows without something like cygwin? From the source distribution, the only way to build ghc seems to be via configure and (GNU) make. So there must be some shell environment available. Or am I missing something really crucial here? Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Using GHC as a library with own functions makes runStmt return RunBreak
Hi I am trying to use GHC as a library. From runStmt, I want to load and run functions from a home-grown module. Lets call my home-grown module HomeGrown.hs. I have tried to model my application after http://haskell.org/sitewiki/images/1/17/Interactive-6.8.hs / http://haskell.org/sitewiki/images/f/f9/MyPrelude.hs from http://haskell.org/haskellwiki/GHC/As_a_library . This library loads MyPrelude.hs and runs myPutStrLn myGetLine + more. However, when I try to run code from HomeGrown.hs like: runStmt session HomeGrown.foo GHC.SingleStep runStmt keeps returning RunBreak (of type RunResult). From what I can read of the WWW, RunBreak is related to some debugger and indicate that GHC encountered some breakpoint. However, I did not set any break points. Comparing Interactive-6.8 and MyPrelude.hs to my own code, the largest difference seemed to be that Interactive-6.8 do not only use MyPrelude.hs by calling `addTarget` and `setContext`, it also imports MyPrelude.hs as a regular Haskell import (import MyPrelude). Thus I tried to remove this import to see what would happen. Interactive-6.8 compiled and started just fine. However, whenever it needed to use any functions in MyPrelude, runStmt also returned RunBreak. So is it only possible to load home-grown/non-standard modules when also doing a regular import? Greetings, Mads Lindstrøm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping for Leopard
Philip K.F. Hölzenspies: I'm trying toupdate the Portfile so that ghc-6.8.2 can be built using MacPorts (handy for installing other ghc-dependent material from MacPorts like gtk2hs). The problem seems to be that the available bootstrap binary http://www.haskell.org/ghc/dist/6.6/ghc-6.6-i386-apple-darwin-bootstrap.tar.bz2 causes a segfault on Leopard (below are the steps I took in my attempt to build ghc with this bootstrap binary). Using Manuel Chakravarty's binary distribution of ghc-6.8.1-i386- apple-darwin building ghc-6.8.2 works fine. It seemed to me that the easiest way to fix the bootstrap problem is to boot from C as described on the wiki (http://hackage.haskell.org/trac/ghc/wiki/Building/Porting). Two things were wrong, however. make hc-file-bundle Making the hc-file-bundle target failed, because not all rts/*.cmm had rts/*.hc counterparts after the build. The make fails because of this fragment from the Makefile (part of the hc-file-bundle target, starting from line 513): for f in `$(FIND) ghc-$(ProjectVersion)/compiler ghc-$(ProjectVersion)/rts -name *.cmm -follow -print` ; do \ if test x$$f !=3D x; then \ echo `echo $$f | sed 's/cmm$$/hc/g' ` hc-files-to-go ; \ fi; \ done; This adds some non-existing .hc files to the hc-files-to-go list that tar will not find, later on, causing an error. I just added a test to see whether the file exists. If it does not, I call make for that .hc file explicitly, which solves the problem for most files. The files that don't have a make target, I simply omitted from the hc-files-to-go. I haven't been able to test the severity of this, because of the second problem. I am not sure what the problem is here. Simon? Ian? checking for ld... /usr/bin/ld checking for path to top of build tree... ./configure: line 2651: - v0: command not found ./configure: line 2655: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory Upon inspection of the configure script, I found out that line 2651 uses the variable designating the ghc compiler. This is due to a change of the configure stage that AFAIK was made to easy building on windows. Instead, of using shell commands/scripts (as GHC did previously) to obtain some configuration information (here the file path at which the top of the GHC build tree is located), the build system now uses small Haskell programs/scripts. This makes the build more portable ** if there is already a Haskell compiler on the system **. It however messes everything up if you want to build from HC files (and so don't have a Haskell compiler). I am not sure whether anybody thought about this problem when the change to using Haskell scripts instead of shell scripts was made. Ian? Simon? The only solution that I see is to replace the Haskell scripts by vanilla shell scripts in HC bundles. Even if that causes problems on windows (without cygwin), it would make HC bundles viable on Unix systems again. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
