RTS interface followup...

[Simon Marlow]

> The code (which is what I am assuming is where the error is=20
> comming from) is
> lifted
> from Linker.lhs, namely (lookupSymbol :: CString -> IO (Ptr=20
> a)) this is used
> in the
> following:
>=20
> 	hobj <- lookupSymbol c_objsym
> 	case hobj of
> 	o | o =3D=3D nullPtr -> return Nothing
> 	Ptr o -> case (addrToHValue# o) of
> 		(# h #) -> return (Just h)
>=20
> [I am not 100% certain this is where the error is comming=20
> 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=20
> stage compile with -c to
> generate all the .o files then a link - using ghc) the=20
> following error is generated:
>=20
> .../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...
>=20
> 	Hope this makes it a bit clearer. A second problem I=20
> 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=20
> 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