cvs commit: fptools/ghc/docs/comm/the-beast driver.html

[Reuben Thomas]

> 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
> itself?

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