RE: RTS interface followup...
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
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)... 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)... Keean Schupke Department of Electrical & Electronic Engineering, Imperial College. -----Original Message----- From: Simon Marlow [mailto:simonmar@microsoft.com] Sent: 17 July 2002 11:19 To: k.schupke@ic.ac.uk Cc: glasgow-haskell-users@haskell.org Subject: RE: RTS interface followup...
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
participants (2)
-
Keean -
Simon Marlow