July 2002 - Glasgow-haskell-users

RE: Document -optl-static
by Simon Marlow 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/option > s-phases.html#OPTIONS-LINKER > 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? I think the -static flag probably ought to be passed to the linker, so you wouldn't need -optl-static. Is there any reason you might need -static but not -optl-static? Cheers, Simon

2 1

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

17 Jul '02

> rts_mkAddr is used by Linker.o in libHSrts.a (it looks like in the > resolveObjs call - I in turn am calling this... (this was > from doing an nm on the library)... Hmm, yes the Linker does refer to it, just in case the dynamically linked program requires it. I think you should probably arrange that the missing symbols get linked in from HSlang.o, something like: ghc -package lang -optl-u -optl Addr_Azh_con_info does that help? > with regards to the threading, I was wondering if the default file > buffering mode has changed, as text IO to the console seems slower > (you can see characters 'printing' left to right, rather than just > lines flying past)... No, the default buffering has not changed. Can you quantify the slowdown, or provide an example? Does it only happen when --enable-threaded-rts is on? Cheers, Simon

2 1

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

17 Jul '02

> The code (which is what I am assuming is where the error is > comming from) is > lifted > from Linker.lhs, namely (lookupSymbol :: CString -> IO (Ptr > a)) this is used > in the > following: > > hobj <- lookupSymbol c_objsym > case hobj of > o | o == nullPtr -> return Nothing > Ptr o -> case (addrToHValue# o) of > (# h #) -> return (Just h) > > [I am not 100% certain this is where the error is comming > from - but its the only reference to an Addr I can find...] There isn't a reference to Addr in the above code, only the primitive type Addr# (which isn't deprecated). > this compiles fine, however in the final link (i'm doing a 2 > stage compile with -c to > generate all the .o files then a link - using ghc) the > following error is generated: > > .../ghc-5.04/libHSrts.a(RtsAPIDeprec.o): In function 'rts_mkAddr': > RtsAPIDeprec.o(.text+0x14): undefined reference to 'Addr_Azh_con_info' RtsAPIDeprec should only be linked in if something requires it - i.e. if one of the symbols rts_getAddr or rts_mkAddr is used elsewhere. Do you have any code which uses one of those functions? > ...same for rts_getAttr, with the addition of the symbol > Addr_Azh_static_info > which is also undefined... > > Hope this makes it a bit clearer. A second problem I > have just found - using > a threaded runtime, my code now hangs after getting a connection on a > socket, and forking > a haskell-thread to handle it. The reply is not sent until another > connection attempt > occurs... where does the behavior of the threaded runtime > differ from the non-threaded? I'm afraid I don't know about this one, I haven't done much testing of the threaded RTS myself (due to lack of time and trying to get 5.04 out of the door). Cheers, Simon

2 1

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