RTS interface followup...

[Keean]

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