- Glasgow-haskell-users

installing 5.02.2
by S.D.Mechveliani 19 Mar '02

19 Mar '02

Dear GHC, I am going to install ghc-5.02.2 on certain Linux machine to which I have ssh access and permission to install ghc-5.02.2 in my user directory (not a system user). The situation is as follows. It has i386-unknown (Pentium Pro II ...), much of memory and disk. I am not sure, but it looks like it is under RedHat-6.2, glibc-2.1.2. It has ghc-4.04 installed in the system area. But it failed to link Main.o of the program main = putStr "hello\n" Probably, Happy, is not installed. Also I applied certain ghc --make M on my Debian Linux machine with ghc-5.02.2, scp -ed the a.out.zip file to the target machine and unzipped it. And it cannot run there, some library not found, something of this sort. Could the GHC installation experts guide me, please? What is easier in this situation, to install from source or from binary? How to install Happy for the first time? How to find out in a regular way the info about Linux system and libc version? Thank you for the advice, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: GHC 4.08.2 on OpenBSD 2.9, almost
by Simon Marlow 18 Mar '02

18 Mar '02

> I'm trying to port any recent version of ghc to OpenBSD 2.9. > > I have, with a little bit of work, been able to compile 4.08.2 > from .hc sources. > > I now get the following kind of undefined symbol errors: > > Main.o: Undefined symbol `__init_Prelude' referenced from text > segment > Main.o: Undefined symbol `PrelBase_unpackCStringzh_closure' > referenced from text segment > Main.o: Undefined symbol `PrelIO_putStr_closure' > referenced from > text segment > > [ ... ] > > PrelMain__1.o: Undefined symbol `___init_Main' > referenced from text > segment > .o::PrelMain(void): Undefined symbol > `_Main_main_closure' referenced > from text segment > .o::PrelMain(void): Undefined symbol > `_Main_main_closure' referenced > from text segment > > My guess is that this kind of thing has happened before > ... is there > an area in the source I should be looking at? This looks suspiciously like a mismatch in the handling of leading underscores in symbol names somewhere. It appears from the messages above that Main.o doesn't have extra leading underscores on its symbols, but the libraries do. Perhaps Main.o was compiled by the native code generator? Because the leading-underscore setting is compiled into the compiler via an external setting, you'll need to bootstrap the compiler before the setting will be correct for your system. Try compiling your test program with -fvia-C. Cheers, Simon

1 0

rts/Printer.c
by Bernard James POPE 18 Mar '02

18 Mar '02

Hi all, I'm looking at extending my debugger for Haskell to GHC (currently only works for Hugs, which is a pity). I have a couple of questions about printing data structures from the GHC heap. Is there a way to compile the RTS so that the names of data constructors are retained? It looks like Printer.c has some hooks for printing data structures, is it feasible to make a primitive that allows Haskell code to call into this? I'm thinking in particular of calling something like printClosure() from Haskell code. Unfortunately my understanding of the rts and the layout of data structures is fading. Cheers, Bernie.

2 1

GHC 4.08.2 on OpenBSD 2.9, almost
by dons＠cse.unsw.edu.au 16 Mar '02

16 Mar '02

Hi, I'm trying to port any recent version of ghc to OpenBSD 2.9. I have, with a little bit of work, been able to compile 4.08.2 from .hc sources. I now get the following kind of undefined symbol errors: Main.o: Undefined symbol `__init_Prelude' referenced from text segment Main.o: Undefined symbol `PrelBase_unpackCStringzh_closure' referenced from text segment Main.o: Undefined symbol `PrelIO_putStr_closure' referenced from text segment [ ... ] PrelMain__1.o: Undefined symbol `___init_Main' referenced from text segment .o::PrelMain(void): Undefined symbol `_Main_main_closure' referenced from text segment .o::PrelMain(void): Undefined symbol `_Main_main_closure' referenced from text segment My guess is that this kind of thing has happened before ... is there an area in the source I should be looking at? Thanks, Don Stewart dons(a)cse.unsw.edu.au

1 0

RE: Strictness of addition functions.
by Simon Peyton-Jones 15 Mar '02

15 Mar '02

| data Pair = Pair !Int# !Int# | | f (Pair x y) = x +# y | | I still discovered to my dismay that the type of the first | argument to f is U(LL). | | What can I do to force the arguments to be strict? Int# is *always* strict. You don't need the !'s. The L is misleading, I suppose. But since Int# means *unboxed* 32-bit integers, there is simply no way you can pass a thunk. Simon

1 0

Strictness of addition functions.
by Sean Seefried 15 Mar '02

15 Mar '02

Lately, I've been attempting to improve the performance of a highly numerically intensive program. Yet try as I might I cannot seem to define (nor find) an addition function that is strict in both its arguments. Using the advice found in the GHC Users Guide I have looked inside the .hi file and discovered that the functions I define are indeed lazy in their arguments. Even when I try something like data Pair = Pair !Int# !Int# f (Pair x y) = x +# y I still discovered to my dismay that the type of the first argument to f is U(LL). What can I do to force the arguments to be strict? ------------------------------------------------ Sean Seefried School of ITEE The University of Queensland Ph: 3365 8301 Mob: 0416 338 636

1 0

RE: HGL ang GHC on Win32
by Simon Marlow 14 Mar '02

14 Mar '02

> That is a shame. I tried both suggestions (specifying > position explicitly > and recompiling with fvia-c -- i had been using O all along) > and neither > worked :(. > > I also tried using 5.03, and got the following warnings: [ message deleted ] It looks like there are some prototypes missing: > C:\DOCUME~1\hdaume\LOCALS~1\Temp\ghc920.hc:59: warning: implicit > declaration of function `prim_rgb' GHC might not generate correct calls to these functions unless there is a visible prototype. In fact, taking this example, the definition of prim_rgb is DWORD prim_rgb(BYTE arg1,BYTE arg2,BYTE arg3) but its FFI declaration says foreign import ccall "prim_rgb" unsafe prim_rgb :: Word32 -> Word32 -> Word32 -> IO (Word32) this looks a bit strange - is there a green-card expert out there to explain what's going on? Why have the BYTEs been turned into Word32s? Cheers, Simon

1 0

RE: HGL ang GHC on Win32
by Simon Marlow 13 Mar '02

13 Mar '02

> I'm hoping that a GHC honcho will say > > "Well of course that happens with 5.02.2 - you should > upgrade to 5.03 right away." > > or some such. I'm afraid not :-) But there *is* a bug in the native code generator in 5.02.2, namly in the FFI support for passing floating point arguments to ccalls, which I fixed yesterday and could potentially cause this kind of problem. Make sure the graphics library has been compiled with -fvia-C or -O to work around it (and if this helps, please let us know). Cheers, Simon

2 1

RE: how to specify gcc location on ghc command line?
by Simon Marlow 13 Mar '02

13 Mar '02

> ghc-5.02.2 seems to need gcc-2.95.3, but here we have > gcc-3.0.* per default. > There IS a gcc-2.95.3 tree around, but how do I tell ghc about it? You can use 'ghc -pgmcgcc-2.95.3' (unfortunately you can't leave a space between -pgmc and gcc-2.95.3 because of a bug in the command-line handling of this option in 5.02.2). If you build GHC yourself, there's a configure-time option to select which gcc to use, namely --with-gcc=<gcc>. Cheers, Simon

1 0

how to specify gcc location on ghc command line?
by Johannes Waldmann 13 Mar '02

13 Mar '02

ghc-5.02.2 seems to need gcc-2.95.3, but here we have gcc-3.0.* per default. There IS a gcc-2.95.3 tree around, but how do I tell ghc about it? -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --

1 0