cvs commit: fptools/ghc/docs/comm/the-beast driver.html
Thu, 23 Aug 2001 09:13:45 +0100 (BST)
> Now, the cycle between the two could have been resolved the
> other way around, so that the RTS would have to appear
> before HSstd, but I assume HSstd is using many more symbols
> from the RTS than the RTS from HSstd. So, resolving the
> cycle the other way would require many more -u options.
That's what we assume, but we haven't checked.
> This does, however, lead to a complication. Normal
> Haskell programs do not have a main function, so this is
> supplied by the RTS. It calls startupHaskell, which
> itself calls __init_PrelMain, which is therefore, since
> it occurs in the standard library, one of the symbols
> passed to the linker. However, when the main function is
> provided by the programmer (e.g. when there is no main
> module, but a C module instead), __init_PrelMain had
> better not be linked in, because it tries to call
> __init_Main, which won't exist.
> This reads to me as if the complication arises only because
> of the business of breaking the cycle between the RTS and
> HSstd. However, I think, this is not true. The RTS has to
> be linked in anyway. So, it will include a `main()', which
> overall leads to `__init_Main' being linked in (with or
> without cycle).
> Have I misunderstood you or do I misunderstand the setup
Well, there's extra complication owing to the -u's, but basically I think
you're right. The main() stuff leads to even more complications under
DLLized systems on Windows, after all. Perhaps I should write something
about that too...
http://sc3d.org/rrt/ | Careful Cyclists Approaching From Right