- Glasgow-haskell-users

RE: package name mismatch
by Simon Marlow 17 Jul '02

17 Jul '02

> It must have been only a warning in 5.02.3, or I could never have > compiled it there. (Before 5.02.3 we didn't use the package > system like this at all.) > > Actually I would like this message to go away altogether in this case, > if possible. The actual situation is that GetPut.hs is in fact part > of the package "uni-events-test", and the compiler is told to load > uni-events-test on the command line. However GetPut.hs is *also* in > the current directory during this compilation, so GHC loads > it from there > instead. I'm not sure what logic would be best here, but my > suggestion > would be that where a .hi file is found in an import declaration and > has an unexpected package name, GHC keeps on searching. If it finds > a .hi file with a matching package name, it accepts it, otherwise > accept the .hi file with the wrong package name and issue a warning. > > If that's too complicated, just ignore .hi files with the > wrong package name. But then people might complain . . . I think this is all way too complicated. GHC's view of modules is fairly simple: they either reside in the home package or another package. If a module occurs in both, then previously it was an error, now it is just a warning. If we were using packages for dynamic libraries, one of the reasons we originally added packages, then it really *would* be an error and you'd be in trouble if you did this! Can't you just fix your build so that the situation doesn't occur? Cheers, Simon

2 2

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