- Glasgow-haskell-users

RE: RTS interface followup...
by Simon Marlow 17 Jul '02

17 Jul '02

> Have got the rts stuff to compile by including > .../ghc-5.04/HSlang.o on the > compile command line. I think this means the linker is not > including the > object > with defines Addr_Azh_con_info when it links the library (only objects > actually > referenced from an archive library get included in the final > binary) however > including > the .o forces all the code in the library to be included. It > looks like a > problem with > the arguments ghc passes to the linker, however passing -optl > --undefined > Addr_Azh_con_info > (should force the linker to output the code containing the > definiton) made > no difference, > so I'm a little confused by that. I'm a bit hazy about this - I remember you were working on doing some dynamic linking of Haskell code, but could you explain in more detail exactly what it is you're doing, and at what point the error is generated? The Addr type is deprecated, so please don't use it if possible. Cheers, Simon

2 1

Document -optl-static
by Volker Stolz 17 Jul '02

17 Jul '02

I think it would be a good idea to add -optl-static to the flags described in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html… perhaps in the vincinity of -static & -dynamic. Although this could be considered redundant, it might save some time trying out how to build entirely static binaries. Opinions? -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.'

1 0

RTS interface followup...
by Keean 17 Jul '02

17 Jul '02

Have got the rts stuff to compile by including .../ghc-5.04/HSlang.o on the compile command line. I think this means the linker is not including the object with defines Addr_Azh_con_info when it links the library (only objects actually referenced from an archive library get included in the final binary) however including the .o forces all the code in the library to be included. It looks like a problem with the arguments ghc passes to the linker, however passing -optl --undefined Addr_Azh_con_info (should force the linker to output the code containing the definiton) made no difference, so I'm a little confused by that. Keean Schupke Department of Electrical & Electronic Engineering, Imperial College.

1 0

RE: System.system broken?
by Simon Marlow 17 Jul '02

17 Jul '02

> is System.system broken in 5.04? i am using the rpm provided > on the web > site and this call appears to be broken. in particular, using strace i > find that it is attempting the following call > > [pid 16975] execve("n/sh", ["/bin/sh", "-c", "echo foo"], [/* > 67 vars */]) = -1 ENOENT (No such file or directory) > > note that it appears the first three characters are being droped from > the first argument to execve. I haven't seen any problems with System.system here (the compiler uses it quite extensively for one). Which flavour of Linux are you on, and do you have a test program we can use to reproduce it? Cheers, Simon

1 0

RE: RtsAPI.h (was Re: new RTS interface problem with ghc-5.04)
by Simon Marlow 17 Jul '02

17 Jul '02

> Following up to Keean's message about problems with the RTS > interface in > ghc-5.04, we have also trouble with that. > > When compiling C code containing call-ins to Haskell, gcc > will complain > about RtsAPI.h as follows: > > /usr/local/lib/ghc-5.04/include/RtsAPI.h:125: syntax error > before `const' > /usr/local/lib/ghc-5.04/include/RtsAPI.h:126: syntax error > before `const' > /usr/local/lib/ghc-5.04/include/RtsAPI.h:125: storage size of > `GHCziTopHandler_runIO_closure' isn't known > /usr/local/lib/ghc-5.04/include/RtsAPI.h:126: storage size of > `GHCziTopHandler_runNonIO_closure' isn't known Two possible workarounds for now: either #include "Rts.h" before "RtsAPI.h", or edit RtsAPI.h directly: in the declarations for GHCziTopHandler_runIO_closure and GHCziTopHandler_runNonIO_closure remove 'DLL_IMPORT'. Also, if you're using GCC 3.1, you might have to remove 'const' too. Cheers, Simon

1 0

RE: Unregisterised build
by Simon Marlow 17 Jul '02

17 Jul '02

> > The cross-port script also tries to do too much. You won't > be able to > > actually run the b2 compiler on your bootstrap box, because > it will be > > built against the Alpha/Linux-specific libraries, so just stop after > > you've got a set of .hc files for ghc/compiler in stage 2. Take the > > library .hc files from stage 1, and the compiler .hc files > from stage 2, > > to your Alpha/Linux box. > > That's where I am now. Running the distrib/hc-build script dies pretty > early on in the ghc subdir: > ... > copying ./mpn/generic/sb_divrem_mn.c to mpn/sb_divrem_mn.c > copying ./mpn/generic/jacbase.c to mpn/jacbase.c > copying ./mpn/alpha/gmp-mparam.h to gmp-mparam.h > ../utils/ghc-pkg/ghc-pkg-inplace --update-package <rts.conf.inplace > /bin/sh: ../utils/ghc-pkg/ghc-pkg-inplace: No such file or directory > make[1]: *** [boot] Error 127 Ok, we'll probably have to hand-hold the build a little. Automatic bootstrapping has rotted slightly, but it should still be possible to get a working compiler. > I tried building that manually, but it seems to be relying on > the presence > of a large amount of libraries (I have all its object files, > but they're > worthless without the libs). Yes, don't worry about ghc-pkg for the moment. The first step is to build the libraries (libraries/base, libraries/haskell98, and most of hslibs). Then build the compiler; at that stage you should have a working compiler binary and it's all downhill from there... > 'make' in ghc/compiler dies with: > > gcc -x c absCSyn/AbsCSyn.hc -o absCSyn/AbsCSyn.raw_s -S -O -mieee > -static -w -D__GLASGOW_HASKELL__=505 -O > -I/home/jameson/work/port/haskell/build/ghc/includes > -I/home/jameson/work/port/haskell/build/libraries/base/include > -I/home/jameson/work/port/haskell/build/hslibs/lang/cbits > -I/home/jameson/work/port/haskell/build/hslibs/posix/cbits > -I/home/jameson/work/port/haskell/build/hslibs/util/cbits > -I/home/jameson/work/port/haskell/build/hslibs/text/cbits > -I/home/jameson/work/port/haskell/build/hslibs/hssource/cbits > -Iparser -I. > -I../includes -O -D__GLASGOW_HASKELL__=505 -I. `echo | sed > 's/^$/-DSTOLEN_X86_REGS=4/'` > absCSyn/AbsCSyn.hc:2: HsStd.h: No such file or directory > absCSyn/AbsCSyn.hc:46: macro `SET_HDR_' used with only 3 args > absCSyn/AbsCSyn.hc:174: macro `SET_HDR_' used with only 3 args > [...] > > followed by more of the same. The only fitting SET_HDR_ seems to be in > common-rts/includes/StgMacros.h. This is very strange - just to be clear, what version of the GHC sources did you start with? There seems to be a version mismatch somewhere - HsStd.h doesn't exist now (last seen in 5.02.X), and SET_HDR_ has an extra argument in 5.04. It looks like you generated your .hc files from the 5.02.x sources, and are building them in a 5.04 or later source tree - that's *not* a good idea, trust me :-) > > At some point we'll try to make all this easier, but I'm > afraid that's > > the way it is at the moment :-( > > NP, it's quite interesting (in a masochistic kind of way ;) > Thanks for your help so far, Your experiences will be useful to us too, when we get around to cleaning up the bootstrapping process. Cheers, Simon

1 0

System.system broken?
by John Meacham 17 Jul '02

17 Jul '02

is System.system broken in 5.04? i am using the rpm provided on the web site and this call appears to be broken. in particular, using strace i find that it is attempting the following call [pid 16975] execve("n/sh", ["/bin/sh", "-c", "echo foo"], [/* 67 vars */]) = -1 ENOENT (No such file or directory) note that it appears the first three characters are being droped from the first argument to execve. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 1

new RTS interface problem with ghc-5.04
by Keean 17 Jul '02

17 Jul '02

I have just moved to ghc-5.04 to try the threaded runtime, however some code I have to do dynaminc module loading using the rts linker will not compile, failing with: RtsAPIDeprec.o undefined reference to Addr_Azh_con_info (in rts_mkAddr) this symbol appears to be defined in libHSlang.a, and I have a -syslib lang in the compile command... what's wrong here? secondly, if this interface is deprecated, (I presume this is something to do with the FFI?) where am I using rts_mkAddr and rts_getAddr, would that be in addrToHValue, and if so what is the non-deprecated way of doing this? Keean Schupke Department of Electrical & Electronic Engineering, Imperial College.

2 1

RE: Unregisterised build
by Christoph Reichenbach 17 Jul '02

17 Jul '02

Hi, [...] > BTW the cross-port script is a little old, so you might find other > problems. As far as I know, unregisterised compilation *does* work > though. I had to do a number of manual compiles, out-of-order makes etc. to get stuff working; I'm not completely convinced that what I'm trying to do is right ATM... [...] > Your best bet for the .hsc files is to generate the .hs on your > Alpha/Linux box by taking the intermediate _hsc.c files over and > compiling/running them on the target machine to get the .hs files. Then > take the .hs back to the bootstrapping machine and carry on. These are > the libraries in stage 1, BTW. Did that. [...] > The cross-port script also tries to do too much. You won't be able to > actually run the b2 compiler on your bootstrap box, because it will be > built against the Alpha/Linux-specific libraries, so just stop after > you've got a set of .hc files for ghc/compiler in stage 2. Take the > library .hc files from stage 1, and the compiler .hc files from stage 2, > to your Alpha/Linux box. That's where I am now. Running the distrib/hc-build script dies pretty early on in the ghc subdir: ... copying ./mpn/generic/sb_divrem_mn.c to mpn/sb_divrem_mn.c copying ./mpn/generic/jacbase.c to mpn/jacbase.c copying ./mpn/alpha/gmp-mparam.h to gmp-mparam.h ../utils/ghc-pkg/ghc-pkg-inplace --update-package <rts.conf.inplace /bin/sh: ../utils/ghc-pkg/ghc-pkg-inplace: No such file or directory make[1]: *** [boot] Error 127 I tried building that manually, but it seems to be relying on the presence of a large amount of libraries (I have all its object files, but they're worthless without the libs). 'make' in ghc/compiler dies with: gcc -x c absCSyn/AbsCSyn.hc -o absCSyn/AbsCSyn.raw_s -S -O -mieee -static -w -D__GLASGOW_HASKELL__=505 -O -I/home/jameson/work/port/haskell/build/ghc/includes -I/home/jameson/work/port/haskell/build/libraries/base/include -I/home/jameson/work/port/haskell/build/hslibs/lang/cbits -I/home/jameson/work/port/haskell/build/hslibs/posix/cbits -I/home/jameson/work/port/haskell/build/hslibs/util/cbits -I/home/jameson/work/port/haskell/build/hslibs/text/cbits -I/home/jameson/work/port/haskell/build/hslibs/hssource/cbits -Iparser -I. -I../includes -O -D__GLASGOW_HASKELL__=505 -I. `echo | sed 's/^$/-DSTOLEN_X86_REGS=4/'` absCSyn/AbsCSyn.hc:2: HsStd.h: No such file or directory absCSyn/AbsCSyn.hc:46: macro `SET_HDR_' used with only 3 args absCSyn/AbsCSyn.hc:174: macro `SET_HDR_' used with only 3 args [...] followed by more of the same. The only fitting SET_HDR_ seems to be in common-rts/includes/StgMacros.h. I'm not sure which of the two approaches I should pursue now and where to look for solutions to these problems (HsStd.h in particular managed to evade all attempts to find(1) it); any ideas or suggestions? > At some point we'll try to make all this easier, but I'm afraid that's > the way it is at the moment :-( NP, it's quite interesting (in a masochistic kind of way ;) Thanks for your help so far, llap, Christoph

1 0

RE: make -j2 fails on SMP with ghc-5.04
by Simon Marlow 16 Jul '02

16 Jul '02

> I have a dual Athlon box, make -j2 fails, but make works. > Is that normal? I did some tweaking to the build system to help -jN builds, but I haven't tested a complete build this way. Whereabouts does it fall over for you? Cheers, Simon

2 1