- Glasgow-haskell-users

RE: Makefile, Linux versions
by Simon Marlow 20 Mar '02

20 Mar '02

> > make docon > ghc -fglasgow-exts -fallow-overlapping-instances > -fallow-undecidable-instances -fno-warn-overlapping-patterns > -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports > -syslib data -ddump-hi-diffs -package-name docon > --make DExport > ghc: input file doesn't exist: docon > ghc: input file doesn't exist: DExport > ghc: no such system library (-syslib): data > ghc: unrecognised option: -package-name > ghc: unrecognised option: --make It looks like you're invoking the wrong version of GHC (perhaps the 4.04 version you mentioned earlier)? Cheers, Simon

1 0

warning: `RLIM_INFINITY' redefined
by S.D.Mechveliani 20 Mar '02

20 Mar '02

Dear ghc-5.02.2-i386-unknown-linux, When compiling with -O, you report sometimes things like In file included from /usr/include/sys/resource.h:25, from /share/nfs/users/internat/mechvel/ghc/5.02.2/inst/lib/ghc-5.02.2/ include/HsStd.h:65, from /tmp/ghc29631.hc:2: /usr/include/bits/resource.h:109: warning: `RLIM_INFINITY' redefined /usr/include/asm/resource.h:26: warning: this is the location of the previous definition Is this harmless? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

sorry for false alarm
by S.D.Mechveliani 20 Mar '02

20 Mar '02

I am sorry. It was a false alarm. I wrote recently about Makefile faults when applying ghc. The is also old ghc on this machine in the system area. I set alias to new ghc (in my user directory), but `make' does not know about alias and applies old ghc, which does not understand some options, like +RTS. This is not a problem. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Makefile tricks
by S.D.Mechveliani 20 Mar '02

20 Mar '02

Dear ghc-5.02.2-i386-unknown-linux, (RedHat-6.1 Linux machine, libc-2.1.2), Can you, please explain the following effect Main.hs: main = putStr "hello\n" Makefile: --------- obj: ghc -c -O Main.hs +RTS -M10m -RTS -- Running -------------------- $ tcsh > make obj ghc -c -O Main.hs +RTS -M10m -RTS ghc: input file doesn't exist: +RTS ghc: unrecognised option: -M10m ghc: unrecognised option: -RTS Now, type this to command line: > ghc -c -O Main.hs +RTS -M10m -RTS And it works. This is so for the lstcsh shell too. > make -v GNU Make version 3.77, by Richard Stallman and Roland McGrath. And it works correct under Debian Linux, GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i586-pc-linux-gnu I do not know, whether it is essential, but this RedHat machine is a claster: for any job started, the system chooses itself appropriate machine to run this job on. But I was told that tcsh switches off this clastering. Also I am not sure, that this refers to GHC. I tried to set obj: ls -la and it works. Maybe, the new ssh version bug? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Makefile, Linux versions
by S.D.Mechveliani 20 Mar '02

20 Mar '02

Dear GHC, I have installed ghc-5.02.2-i386-unknown-linux in my user directory on RedHat-6.1 Linux machine, libc-2.1.2 to which I have ssh access. My DoCon program was tested on Debian Linux. Now, it fails to `make' under RedHat in the following way. 1. It loads some shell wich shows the $ prompt. $ echo $shell /bin/lstcsh DoCon `make' was tested under tcsh. Also this RedHat machine is a claster: for any job started, the system chooses itself appropriate machine to run this job on. But I was told that tcsh switches off this clastering. So, for these two reasons, I command tcsh before `making' DoCon. 2. And it fails as follows: > make docon ghc -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -syslib data -ddump-hi-diffs -package-name docon --make DExport ghc: input file doesn't exist: docon ghc: input file doesn't exist: DExport ghc: no such system library (-syslib): data ghc: unrecognised option: -package-name ghc: unrecognised option: --make Under lstcsh, it reports the same thing. If I copy this command by mouse and run it not via Makefile but from the command line, then it works. The strings like -ddump-hi-diffs -package-name docon are kept in the varibles defined and used in Makefile like this: o1 = -ddump-hi-diffs -package-name docon obj: ghc $(o1) ... I wonder about this effect. How can one fix this Makefile business? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: rts/Printer.c
by Simon Marlow 19 Mar '02

19 Mar '02

> > Is there a way to compile the RTS so that the names of data > > constructors are retained? > > My memory from a long, long time ago is that we had a debugging mode > which used libbfd to get symbol names and some GHC-demangling code to > turn those back into names like the user typed in. Yes, we still have that code, but it doesn't get much use - gdb can map addresses back to symbol names. I think I always intended to beef this up using a proper hash table for the address->symbol mapping, but never got around to it. Alternatively, if you compile for profiling, then info tables contain some extra information including the constructor name for contructors. > > 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. > > If it's a global symbol, you should be able to access it form the ffi. > > If you want to traverse data structures the way you can using the > HugsInternals library, you might want to tweak the code a little to > provide a similar semantics/ API. Basically, all you have to do is > take the C code and split it into handy bits. This is a nice idea - we'll be happy to incorporate the changes. Cheers, Simon

3 2

RE: Linux version, libraries
by Simon Marlow 19 Mar '02

19 Mar '02

> uname -a > Linux ...<machine>... > 2.2.12 #6 SMP mar oct 5 16:44:59 CEST 1999 i686 unknown > > ls -l /lib/libc* > > -rwxr-xr-x 1 root root 4118299 Sep 20 1999 /lib/libc-2.1.2.so* > lrwxrwxrwx 1 root root 13 Nov 5 1999 /lib/libc.so.6 -> > libc-2.1.2.so* > lrwxrwxrwx 1 ... 1999 /lib/libcom_err.so.2 -> > libcom_err.so.2.0* > -rwxr-xr-x 1 root root 7889 Oct 26 1999 /lib/libcom_err.so.2.0* > -rwxr-xr-x 1 root root 64595 Sep 20 1999 /lib/libcrypt-2.1.2.so* > lrwxrwxrwx 1 .. 1999 /lib/libcrypt.so.1 -> > libcrypt-2.1.2.so* It looks like it might be a bit earlier than RedHat 6.2, our machine here has libc-2.1.3. The RedHat 6.2 bundle should work fine. One possible way to tell what your system is: > rpm -qa | grep redhat redhat-release-6.2-1 rpmdb-redhat-6.2-0.20000308 redhat-logos-1.1.0-2 > On GMP library: > > > find /usr/lib -name '*gmp*' > > /usr/lib/libgmp.so.2.0.2 > /usr/lib/libgmp.so.2 > find: /usr/lib/netscape/de/nethelp: Permission ... > /usr/lib/perl5/5.00503/i386-linux/linux/igmp.ph > /usr/lib/perl5/5.00503/i386-linux/netinet/igmp.ph Well, you have GMP 2 installed by the looks of it. I don't know why GHC 4.04 is failing, but it's probably not worth tracking down. Cheers, Simon

1 0

Linux version, libraries
by S.D.Mechveliani 19 Mar '02

19 Mar '02

To my >> How to find out in a regular way the info about Linux system and >> libc version? Simon Marlow writes > Try 'uname -a' & 'ls -l /lib/libc*'. uname -a Linux ...<machine>... 2.2.12 #6 SMP mar oct 5 16:44:59 CEST 1999 i686 unknown ls -l /lib/libc* -rwxr-xr-x 1 root root 4118299 Sep 20 1999 /lib/libc-2.1.2.so* lrwxrwxrwx 1 root root 13 Nov 5 1999 /lib/libc.so.6 -> libc-2.1.2.so* lrwxrwxrwx 1 ... 1999 /lib/libcom_err.so.2 -> libcom_err.so.2.0* -rwxr-xr-x 1 root root 7889 Oct 26 1999 /lib/libcom_err.so.2.0* -rwxr-xr-x 1 root root 64595 Sep 20 1999 /lib/libcrypt-2.1.2.so* lrwxrwxrwx 1 .. 1999 /lib/libcrypt.so.1 -> libcrypt-2.1.2.so* But how to find whether it is RedHat (version) ? On GMP library: > find /usr/lib -name '*gmp*' /usr/lib/libgmp.so.2.0.2 /usr/lib/libgmp.so.2 find: /usr/lib/netscape/de/nethelp: Permission ... /usr/lib/perl5/5.00503/i386-linux/linux/igmp.ph /usr/lib/perl5/5.00503/i386-linux/netinet/igmp.ph ? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: rts/Printer.c
by Simon Marlow 19 Mar '02

19 Mar '02

> Say, for argument's sake, that I want to make the function > printObj() available in Haskell, where: > > void printObj (StgClosure *obj); > > (as defined in and exported from rts/Printer.c) > > In Haskell I want to reflect this as: > > printObj :: a -> IO () The FFI doesn't really provide for this sort of thing, because it assumes that any data you want to pass to the outside world will be marshaled into something that the far end can understand (a C data structure, say) before being passed. Passing the raw address of the Haskell value on the heap is a bit dodgy, because the RTS will move these objects around from time to time. It's good practice to instead pass a StablePtr to the value. So you really want something like foreign import ccall unsafe printObj :: StablePtr a -> IO () and use deRefStablePtr() inside printObj to get at the real pointer. Note that this might still break in a threaded environment unless you take care to prevent other parts of the system from modifying the heap while you inspect it, but I wouldn't worry too much about that right now. > Alistair mentioned that I could use the FFI to access some C code > in the RTS. > > My intuition would have been to go about adding a primop as > described in > /ghc/compiler/prelude/primops.txt (ie without calling through > the FFI). primops are a little harder to add than FFI calls, and are generally used for two reasons: when you want the compiler to know more about the underlying operation (eg. so it can do constant folding) or because the compiler can directly generate inline code for the operation. An FFI call is clearly the way to go here. Cheers, Simon

1 0

RE: installing 5.02.2
by Simon Marlow 19 Mar '02

19 Mar '02

> 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). Then you need to get the normal .tar.gz binary bundle. The RPMs will only install in the system directories. > 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. The binary bundle was built on RedHat 6.2, so you should be fine. > It has ghc-4.04 installed in the system area. > But it failed to link Main.o of the program main = putStr "hello\n" Do you mean ghc-4.04 failed to link the program? What was the error message? > Probably, Happy, is not installed. You don't need Happy to install binaries, only if you build from source (and even then, building from a normal source distribution doesn't require Happy because we provide the Happy-generated sources. You might need to tweak the configure script to avoid it complaining about a missing Happy though.). > 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. This is to be expected - shared libraries are bound to differ between the various flavours and versions of Linux distributions. > Could the GHC installation experts guide me, please? > What is easier in this situation, to install from source or > from binary? If it is a RedHat 6.2 (or close) system, then installing the .tar.gz binary bundle should work fine. If not, you may need to try to convince the system admin to install an RPM package for you. > How to install Happy for the first time? There are various binaries of Happy. If none of them work for you, then Happy has to be built from source using GHC. Happy isn't necessary for building GHC from source. > How to find out in a regular way the info about Linux system and > libc version? Try 'uname -a' & 'ls -l /lib/libc*'. Cheers, Simon

1 0