- Glasgow-haskell-users

GHC 6.6.1 Build failure on plain vanilla linux i686 build
by Robin Bate Boerop 29 Jun '07

29 Jun '07

My build dies very soon after issuing "make". Here are the last few lines. Does anyone know what is happening and how to fix it? (The floating constant of which the error message speaks is __GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC 6.4 installed, BTW. /sec/bin/ghc -optc-O -optc-I. -optc-Iinclude -optc-D__GHC_PATCHLEVEL__=2.20060331 -optc-I../libraries/base/cbits -optc-I../libraries/base/include -H16m -O -I. -Iinclude -Rghc-timing -ignore-package Cabal -I../libraries -fglasgow-exts -no-recomp -c cbits/unicode.c -o cbits/unicode.o cbits/unicode.c:1:63: error: floating constant in preprocessor expression <<ghc: 13597044 bytes, 3 GCs, 103440/103440 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (0.17 elapsed), 0.01 GC (0.02 elapsed) :ghc>> make[2]: *** [cbits/unicode.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1

2 3

Re: 64-bit windows version?
by Peter Tanski 26 Jun '07

26 Jun '07

> skaller wrote: > >> On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: >> >>> Bulat Ziganshin wrote: >>> >>>> Hello glasgow-haskell-users, >>>> >>>> are you plan to implement 64-bit windows GHC version? >>>> >>> The main thing standing in the way of this is the lack of a 64- >>> bit port of >>> mingw. >>> >> >> Why do you need mingw? What's wrong with MSVC++? The largest problem is the build system: GHC uses autoconf with custom makefiles. I have looked into porting the whole thing to a Visual Studio project, using SCons (unreliable), CMake (limited command line abilities--good for a one-shot build but really just a "safe" lowest-common-denominator version of Make), Waf (another python-based build system that started as a fork of SCons for the KDevelop changeover from Autotools) and Jam. I would prefer to use Jam but I'm afraid I would be the only one who would ever want to support it. Nothing has the auto-configuration abilities you (John) built into the Felix Interscript-based system but I do not porting the build system (at least) to Interscript would go over well with anyone else who wanted to maintain it and the build itself would require heavy customisation. I have tested all of these on a small scale (the replacement-Integer library). The best option seems to be to create a VS project (not trivial--lots of glue) so a user may also call that from Make (if under Mingw) or pure DOS. There is also some gcc-specific code in the RTS (inline assembler, use of extern inline, etc.) By the way, as of gcc-4.2 (I believe; I know it is true for gcc-4.3) the use of 'extern inline' now conforms strictly to the C99 standard so we will have to add the option '- fgnu-89-inline' to get the old behaviour back--'extern inline' is used in some of the headers. Converting those 'extern inline's to 'static inline' or best yet plain 'inline' would also solve the problem. Ian Taylor's message at http://gcc.gnu.org/ml/gcc/2006-11/ msg00006.html describes this in greater detail; his proposal was implemented. > I don't think we'll be able to drop the mingw route either, mainly > because while > the MS tools are free to download, they're not properly "free", and > we want to > retain the ability to have a completely free distribution with no > dependencies. I don't know of any completely free 64-bit compilers for Windows. The Intel compilers are free for 30-day evaluation but everything else is for Win32. For the base Win32-native port there are many compilers available but I have mostly worked on using CL and Yasm (assembler) as replacement back-end compilers for GHC. > There are people that want a Cygwin port too; personally I think > this is heading > in the wrong direction, we want to be more "native" on Windows, > using the native > object format and interoperating directly with the native Windows > tools. Cygwin has a real problem with gcc: it is far behind everything else (gcc-3.4.4, though Mingw isn't much better) and it doesn't look like that will change anytime soon. It is also only 32-bit, I believe. Cheers, Pete

8 29

hpux 11.0 floating point alignment problem in PrimOps.cmm
by Joe Buehler 26 Jun '07

26 Jun '07

I am getting a floating point alignment exception during a GHC 6.4.2 bootstrap on hpux 11.0 -- the stage 1 ghc core dumps. The stack trace looks like this: (gdb) where #0 0x1ac0df8 in __gmpn_mul_1 () #1 0x1abdd24 in __gmpz_mul () #2 0x1aa2ef4 in timesIntegerzh_fast () #3 0x1ab8124 in StgRun () #4 0x1a9bc08 in schedule () #5 0x1a9c5f4 in waitThread_ () #6 0x1a9c52c in scheduleWaitThread () #7 0x1a99a88 in rts_evalLazyIO () #8 0x1a990dc in main () (gdb) The timesIntegerzh_fast routine is calling into libgmp, libgmp is then core dumping because of an access to a double with bad alignment -- it is trying to load a double from a 4-byte aligned address -- hpux requires 8 byte alignment. The code for timesIntegerzh_fast comes from PrimOps.cmm. It is making use of these memory locations: section "bss" { mp_tmp1: bits8 [SIZEOF_MP_INT]; } section "bss" { mp_tmp2: bits8 [SIZEOF_MP_INT]; } section "bss" { result1: bits8 [SIZEOF_MP_INT]; } section "bss" { result2: bits8 [SIZEOF_MP_INT]; } Might this alignment problem be fixed by adding in some "align 8" statements? Joe Buehler

1 0

Build Systems (was: Re: 64-bit windows version?)
by Peter Tanski 25 Jun '07

25 Jun '07

Gour wrote: > Have you seen Aap (http://www.a-a-p.org/) ? I have A-A-P (or Aap) but I only did the basic hello-world build and read the manual. It has in fact been updated as late as Febuary 2007. The Make-like syntax is elegant. Maybe someone else could look at this and see if they want to do something big in it? One thing that would have to be done for Haskell is write special Aap modules. The builtin ability to grab sources from CVS and publish things to the web might be extended to darcs and Trac. My one gripe is that it requires both Python and Perl. Cheers, Pete

1 0

need help with 6.4.2 boot build for hpux 11.0
by Joe Buehler 25 Jun '07

25 Jun '07

I am attempting to get 6.4.2 booted under hpux 11.0 following the instructions for building from hc files generated on another machine. The target compiler builds but will not build a trivial test program. The error message indicates that it cannot import the Prelude module. Looking at the system calls that the compiler is making I am guessing that package.conf.inplace is not correct. The one produced by the target build is basically empty, as compared to the one on the host machine. Can this file just be copied from the host build machine to the target? Another question I have is this, is there a better version of GHC to try this with? The instructions don't match the 6.6 source tree layout so I went back to 6.4.x. I have had to install some patches though so am wondering if I would have an easier time of this with something even earlier? -- Joe Buehler

1 0

64-bit windows version?
by Bulat Ziganshin 24 Jun '07

24 Jun '07

Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

11 27

ghc6.6 on ps3 - compile error in StgCRun
by Tristan Allwood 24 Jun '07

24 Jun '07

Hi, I'm trying to build ghc-6.6 on a sony ps3, but have hit a problem: ------------------------------------------------------------------------ == make all -r; in /home/tora/ghc/ghc-6.6/rts ------------------------------------------------------------------------ ../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-DNOSMP -optc-fno-strict-aliasing -H16m -O -optc-O2 -optc-DNOSMP -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o /tmp/ghc12557_0/ghc12557_0.s: Assembler messages: /tmp/ghc12557_0/ghc12557_0.s:12:0: Error: junk at end of line, first unrecognized character is `@' /tmp/ghc12557_0/ghc12557_0.s:16:0: Error: junk at end of line, first unrecognized character is `@' make[1]: *** [StgCRun.o] Error 1 make: *** [stage1] Error 1 The ps3 is running YDL, and to bootstrap the ghc build I managed to install a powerpc ghc6.6 on the system (downloaded a deb from http://packages.debian.org/cgi-bin/download.pl?arch=powerpc&file=pool%2Fmai… then alien'ed it to get an rpm which seems to work - though ghci is non-functioning) The sources I'm trying to build are the standard ghc http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src.tar.bz2 (and extralibs) >uname -a Linux ebony 2.6.16-20061110.ydl.2ps3 #1 SMP Tue Dec 5 12:35:42 EST 2006 ppc64 ppc64 ppc64 GNU/Linux Any tips / pointers / advice greatfully recieved; TIA, Tristan Allwood

3 5

ghc configure
by C.M.Brown 23 Jun '07

23 Jun '07

Hi, I've noticed that when you run ./configure on a ghc build lot's of repetition occurs. A lot of the time the same checks are being performed for each configure file in the ghc hierarchy. Could it be possible if some of these checks could be done once at a high level and then subsequent configures could refer to these checks to speed up configuration time? It's just configuring ghc on a mac G4 is a very time consuming process in it's own right! Thanks, Kind regards, Chris.

4 5

Re: 64-bit windows version? (Haskell is a scripting language too!)
by Peter Tanski 22 Jun '07

22 Jun '07

Brian Hulley wrote: > To port GHC to a completely new platform, you'd of course need a > Haskell > compiler or interpreter already. However to bootstrap the process > only a > slow interpreter would be needed so as long as a portable pre-built > bytecode version was available for download the only thing left to > port > would be a byte code interpreter which could just be a single file > of c > code. This was one void Yhc was designed to fill, especially by compiling to java bytecode. At the rate I work--if I'm the only one deconstructing the current build system--by the time I'm done the Yhc team will have everything running. Greg Fitzgerald wrote: > I was trying to build something like this recently but hit a > roadblock. > ... > Unfortunately, the imported module needs to have the line "module > X.Y.Zwhere", which means the file needs to be aware of its parent > directories. I > think that's too harsh a constraint, and makes it a pain to move > things > around (true in everyday Haskell projects with local modules too!). Have you looked at Neptune? It is a scriptable build system based on Jaskell, which allows dynamic imports. An example from the page at http://jaskell.codehaus.org/Jaskell+for +Neptune#JaskellforNeptune-90: //in script1.jsl 1+x where x = import {file="script2.jsl"}; end You may imagine that the string for "script2.jsl" may be computed. Of course this sort of thing breaks the type system in Haskell and the result is more Make-like, but that is the tradeoff. Now why did I not try a build system using Neptune? Probably because I had already spent the last three weeks learning CMake, the pecularities of SCons, WAF (weird bugs!), m4 (I never had to write tests in Autoconf before or debug my own configure files), and higher level Make (so it would do what I can do in Jam)--I guess it got lost by the wayside... I was looking at things most people would either already know or would want to learn and that should already be available on new platforms. skaller wrote: > The second is simply that dynamic typing is generally > better for build systems, because it allows code to > 'self-adapt'. There is a somewhat slow-going scheme-based-build-system project called Conjure, at http://home.gna.org/conjure/ but it only supports Linux and OS X. > An alternative is to implement the build system in, say, > Scheme, and then write a Scheme interpreter in Haskell. > Scheme can self-adapt internally because its compiler > is built-in. That is why I was looking into using SISC--it is self-contained and may even be distributed along with the source code (SISC itself is GPLv2 but that doesn't matter for _using_ it)--by default it looks in the current directory. The downside is the lack of a library with directed graphs. Cheers, Pete

1 0

Template Haskell [d| .. trouble
by Marc Weber 21 Jun '07

21 Jun '07

Hi. I've started using template haskell (replacing some preprocessor stuff) However I had real trouble when trying to convert instance (Show d) => Show (C d) where show _ = "C " ++ (show (undefined :: d)) into th. Why? It didn't compile (http://hpaste.org/289) Heffalump on #haskell suggested that the d is already in scope so I don't need the first list item of ForallT .. And that does work fine. So is this a bug in the [d| .. parser / to abstract syntax tree transformer ? Session showing this behviour: marc@localhost ~ $ cat ABC.hs {-# OPTIONS_GHC -fglasgow-exts #-} module ABC where data C d marc@localhost ~ $ ghci -fth ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :l ABC [1 of 1] Compiling ABC ( ABC.hs, interpreted ) Ok, modules loaded: ABC. *ABC> :m +Language.Haskell.TH *ABC Language.Haskell.TH> runQ [d| instance (Show d) => Show (C d) where show _ = "C " ++ (show (undefined :: d)) |] >>= print Loading package template-haskell ... linking ... done. [InstanceD [AppT (ConT GHC.Show.Show) (VarT d_0)] (AppT (ConT GHC.Show.Show) (AppT (ConT ABC.C) (VarT d_0))) [FunD show [Clause [WildP] (NormalB (InfixE (Just (LitE (StringL "C "))) (VarE GHC.Base.++) (Just (AppE (VarE show) (SigE (VarE GHC.Err.undefined) (ForallT [d_1] [] (VarT d_1))))))) []]]] *ABC Language.Haskell.TH> Now (ForallT [d_1] [] (VarT d_1) should be (ForallT [] [] (VarT d_1) shouldn't it? Marc Weber

2 1