- Glasgow-haskell-users

HEAD: Problem with compat/cbits/unicode.c
by Reilly Hayes 10 May '06

10 May '06

compat/cbits/unicode.c contains the following line: #if __GLASGOW_HASKELL__ < 604 || (__GLASGOW_HASKELL__==604 && __GHC_PATCHLEVEL__==0) __GHC_PATCHLEVEL__ is set by compat/Makefile to be equal to GhcPatchLevel, which seems to be set to the patch level of the INSTALLED Ghc compiler. If there is no installed Ghc compiler, __GHC_PATCHLEVEL__ is blank and unicode.c fails to compile because && wants another operand. I took the lazy to this by setting GhcPatchLevel in my mk/build.mk file. Reilly Hayes rfh(a)reillyhayes.com

2 1

Unregisterised GHC 6.4.2 on the ARM success -- now what?
by Jeremy Shaw 10 May '06

10 May '06

Hello, I believe I have successfully got an unregisterised version of ghc 6.4.2 compiled for arm/linux. Details: ------- I only had to do a minor bit of hacking -- this bug contains the details of what went wrong: http://hackage.haskell.org/trac/ghc/ticket/762 My target platform is the nokia 770 which runs linux and has an arm9 processor. I compiled ghc using the standard nokia 770 cross-development tools. These consist of a debian-based distro named maemo running inside scratchbox using QEMU to emulate the ARM processor. I have successfully compiled a "hello, world!" program and run the executable on the real nokia 770 device. What Next? ---------- The next step appears to be to registerise the build. I found a document that describes the C calling conventions for the ARM: http://www.arm.com/miscPDFs/8031.pdf I think the next step is to add an ARM section to: ghc/includes/MachRegs.h Is there some sensible method for doing this and testing it before I tackle the other pieces ? Thanks! j.

4 7

HEAD: problems with suffix.mk for registerised hc-boot
by Reilly Hayes 10 May '06

10 May '06

The rules in suffix.mk don't seem to work for building in $(TOP)/ compiler/stage1 when building from .hc files. Make dies complaining that it doesn't know how to build the .o file. The relevant rules are: -------- # with mangling $(odir_)%.raw_s : %.hc $(CC) -x c $< -o $@ -S -O $(HC_BOOT_CC_OPTS) -I. `echo $(patsubst - monly-%-regs, -DSTOLEN_X86_REGS=%, $(filter -monly-%-regs, $ ($*_HC_OPTS))) | sed 's/^$$/-DSTOLEN_X86_REGS=4/'` $(odir_)%.s : %.raw_s $(MANGLER) $< $@ $(patsubst -monly-%-regs, %, $(filter -monly-%- regs, $($*_HC_OPTS))) $(odir_)%.o : %.s $(CC) -c -o $@ $< -------- The problem is that the dependency chain is broken when the source & build directory are different. Assuming that .raw_s and .s files belong in the build directory (stage1, etc), I believe the rules should look like: -------- # with mangling $(odir_)%.raw_s : %.hc $(CC) -x c $< -o $@ -S -O $(HC_BOOT_CC_OPTS) -I. `echo $(patsubst - monly-%-regs, -DSTOLEN_X86_REGS=%, $(filter -monly-%-regs, $ ($*_HC_OPTS))) | sed 's/^$$/-DSTOLEN_X86_REGS=4/'` $(odir_)%.s : $(odir_)%.raw_s $(MANGLER) $< $@ $(patsubst -monly-%-regs, %, $(filter -monly-%- regs, $($*_HC_OPTS))) $(odir_)%.o : $(odir_)%.s $(CC) -c -o $@ $< -------- Reilly Hayes

2 1

Problems building HEAD
by Reilly Hayes 10 May '06

10 May '06

I'm trying to build head (latest try with ghc-6.5.20060429) for my macbook pro (Mac OS X intel) using hc files built on a x86 linux (Ubuntu Breezy Badger). I have the following issues: 1) Issues with bookstrap.mk bootstrap.mk in head contains the following lines TOP_SAVED := $(TOP) TOP:=$(TOP)/ghc include $(TOP)/mk/version.mk include $(TOP)/mk/paths.mk # Reset TOP TOP:=$(TOP_SAVED) However, those files are not at those locations. Looking back at 6.4.2, it seems that they were in those locations in 6.4.2, but that changes in the directory structure mean that the line that sets top to $(TOP)/ghc is obsolete. version.mk is nowhere to be seen, nor is version.mk.in. It looks as if the variables set in this file are now set in config.mk and that version.mk is no longer required. If that's true, I can replace all of the lines above with: include $(TOP)/mk/paths.mk 2) Building the .hc files The building guide says that I can build hc files on another host running on the same platform. The word platform seems to be used to describe architecture in some places and architecture & O/S in others. I have assumed that it means architecture in this case (if we already have a compiler that runs on the same Arch & OS, why are we porting). What the building guide does not do is provide instructions for producing registerized hc files. The recipe I have stumbled onto is this a) Create mk/build.mk and add the following lines: GhcLibHcOpts = -O -fvia-C -keep-hc-files GhcRtsHcOpts = -keep-hc-files GhcStage1HcOpts = -O -fvia-C -keep-hc-files GhcStage2HcOpts = -O -fvia-C -keep-hc-files b) run "./configure" c) run "make" d) I want to run "make hc-file-bundle Project=ghc", but it complains about a few missing files. So first I cd to rts and run "make AutoApply.hc AutoApply_p.hc AutoApply_thr.hc \ AutoApply_thr_p.hc AutoApply_debug.hc AutoApply_thr_debug.hc" e) run "make hc-file-bundle Project=ghc", which works just fine. f) untar the resulting file in the parent directory of ghc-6.5.20060429 on the target machine 3) running the build. I'm following the steps in distrib/hc-build by hand, which work out to: ./configure --enable-hc-boot make -C utils boot all make -C ghc boot make -C libraries boot all GhcBootLibs=YES make -C ghc all Is this all correct? I'm having problems with the build in utils, but by then I've already made enough assumptions about how to fix the build that there's little point in asking the question until I've verified that I haven't messed things up upstream. Reilly Hayes

3 3

Browsing the darcs repositories
by Juanma Barranquero 10 May '06

10 May '06

(This one is for the developers) Hi. Are you planning to set up the darcs CGI script (or something equivalent) so it is possible to browse changes/patches in the main repository? Thanks, /L/e/k/t/u

2 1

Alias for :quit in GHCi?
by Juanma Barranquero 09 May '06

09 May '06

Trivial question, just out of curiosity. Why it is not possible to define aliases for :quit in GHCi? Prelude> :def ayuda \_ -> return ":help" Prelude> :def adios \_ -> return ":quit" Prelude> :ayuda ... normal help output... Prelude> :adios Prelude> -- /L/e/k/t/u

2 2

GHC 6.6 and Ticket #608
by Reilly Hayes 09 May '06

09 May '06

Any chance of getting ticket #608 onto the list for the 6.6 release? Ticket #608 is "Make the NCG able to compile the RTS". Please correct me if I am wrong, but my understanding of the dependencies suggests that this is the key obstacle to dynamically linked builds on x86 platforms. My reasoning is that GCC generated position independent code conflicts with the Mangler and that the RTS is the only code that must be built with the Mangler. Reilly Hayes

2 1

Conflict in HEAD between suffix.mk and config.mk.in
by Reilly Hayes 07 May '06

07 May '06

config.mk.in defines MANGLER while suffix.mk uses GHC_MANGLER. I have changed suffix.mk in my build directory to use MANGLER, but GHC_MANGLER is more consistent with the variables used to construct MANGLER (GHC_MANGLER_DIR & GHC_MANGLER_PGM) Reilly Hayes rfh(a)reillyhayes.com

1 0

Re: [Haskell-cafe] Porting GHC to OSX86?
by Reilly Hayes 06 May '06

06 May '06

You'll get a better response to this on the glasgow-haskell-users list. I'm cross-posting my reply. I'm brand new to hacking on GHC, but I've been working on this in my pitifully meagre spare time. The actual expert is Wolfgang Thaller, but he doesn't seem to be around the lists lately. I was able to generate hc files on a 386 linux box (actually on a Parallels virtual machine on my mac, as my linux boxen all run 64 bit linuces). I'll share my findings so far: 1) STABLE does not have the appropriate code in the Mangler to deal with Darwin/86. I've been playing with various versions of HEAD. 2) HEAD has gone through a major revision to the directory structure. The documentation and some of the build processes have not caught up. Simon Marlow sent a helpful e-mail to the ghc users list a few days ago that you should look at. 3) Building the .hc files mostly requires the appropriate settings in mk/build.mk on the Host (linux) machine. I'll include my build.mk below. There is a target in the top level makefile called hc-file- bundle (which needs to be invoked with the parameter ProjectNameShort=ghc in HEAD and Project=ghc in STABLE). This target packages up the .hc files, but does not build them. Some of the .hc files in utils (genapply, genprimopcode, & ghc-pkg) don't get built. I just cd to the directories and make them by hand (be sure to use the in-place compiler). A GhcUtilsHcOpts variable in the make structure would be nice (in order to pass -keep-hc-files to ghc when building these on the host). 4) I have been working with Registerised hc files. This may have been a mistake, as registerised code seems to present some unique challenges on Darwin/86. See the items below for a discussion. 5) If I understand correctly (somebody with better knowledge please correct me), there is a register allocation conflict between ghc and relocatable code generated by gcc on the 386 (gcc flag -fPIC). This limits ghc to producing static binaries. The gcc in Xcode builds relocatable code by default and requires -static to build static binaries. I think this conflict is limited to code that goes through the Mangler (registerized code). 6) If I understand correctly, there is code in the RTS that cannot be built using the native code generator. Which suggests that we're stuck with static binaries. There is a ticket to fix this in HEAD. 7) Mac OS X really doesn't like static binaries. In fact, in order to link a static binary, you have to go to opendarwin and download the Csu package to build crt0.o. It's not included in any of the development tools. Apple warns that static binaries are likely to fail to operate in O/S version changes. Curently I'm fighting with the Makefiles to figure out how to get the -static flag stuffed into all of the invocations of gcc. Some of the invocations in rts components don't seem to obey the normal variables used in the makefile structure. I haven't had time to puzzle this out and won't for a few days. mk/build.mk used to generate hc files: GhcLibHcOpts = -O -fasm -keep-hc-files GhcRtsHcOpts = -fasm -keep-hc-files GhcWithInterpreter = NO GhcStage1HcOpts = -O GhcStage2HcOpts = -O -fasm -keep-hc-files SRC_HC_OPTS += -H32m -reilly hayes On May 5, 2006, at 7:34 PM, Scott Weeks wrote: > Hi All, > > Does anyone know if there's been any headway on this? If there's not > a port available, where do I go about finding the hc files? Could I > compile on a windows or linux x86 box and use the generated hc files > to bootstrap? > > Cheers, > Scott > > On 22/03/2006, at 7:09 AM, Deling Ren wrote: > >> Hi there, >> >> Has anyone made any attempt to port GHC to Mac OS X on x86? >> Wolfgang Thaller’s binary package runs over Rosetta but slow (not >> surprising). It can not be used to compile a native version either >> (I got some errors related to machine registers). >> >> I tried to do a bootstrap but can't find the ".HC" files mentioned >> in the manual. They don't seem to be on the download page of GHC. >> Any ideas? >> >> Thanks. >> >> Deling_______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe Reilly Hayes rfh(a)reillyhayes.com

1 0

Building head & numerics project
by Creighton Hogg 06 May '06

06 May '06

Hi, So I'm interested in working on the project on improving numerics performance in GHC proposed on the SoC page here http://hackage.haskell.org/trac/summer-of-code/ticket/13 Since I have a full time job, I'd just like to do this on my own time rather than take up an SoC slot. In that vein, Don Stewart suggested that the first thing to do was check out the most recent ghc code from darcs and build it. Well, I've been getting the same problems as here http://hackage.haskell.org/trac/ghc/ticket/715 and I was wondering if anyone knew of a workaround or if we could figure out an environment set up that *could* build ghc correctly. Thanks, Creighton Hogg

4 6