[project @ 2000-07-20 17:06:41 by rrt]
authorrrt <unknown>
Thu, 20 Jul 2000 17:06:41 +0000 (17:06 +0000)
committerrrt <unknown>
Thu, 20 Jul 2000 17:06:41 +0000 (17:06 +0000)
commitba5a490c97bacb765d53922c792e6309f833a2d4
treef14e72a3499c576f6871d1e490d07074ba3069e5
parent8e3dd3c9bc269f7d6a12c361ca17ddea72b9d760
[project @ 2000-07-20 17:06:41 by rrt]
What's the story, Rory?

   My name's not Rory. Owing to circumstances not fully understood, the RTS
   used to work DLLized, even though it was largely broken. Unfortunately,
   this was recently fixed.

What used to happen?

   The EF_ macro from StgMacros.h was used to refer to primops &c.

Why was this a Bad Thing?

   Because you need to use EDF_ when building with DLLs.

What was the result?

   primops such as divExactInteger were compiled as _divExactInteger, rather
   than __imp__div_Exact_Integer, so they didn't refer to the DLL routines.

How on earth did it work?

   I'm not sure, but somehow the code for the relevant routines got linked
   into the import libraries (e.g. libHSrts_imp.a), and were thus linked
   statically into the final binary.

So that explains why the import libraries (supposedly just containing stubs)
were larger than the DLLs they were stubbing, or the static libraries, for
that matter?

   Perhaps.

Golly!

   Indeed.

What caused this code leakage?

   That's what I don't know. Perhaps a bug in the Cygwin DLL-building tools?
   I've upgraded from B20.1 to 1.1 recently.

So, what's the hack, Mac?

   My name's not Mac. I added a new macro, ERTSF_, which uses DLL_IMPORT_RTS
   to make sure that the Right Thing is always done (because you mustn't
   make DLL references to RTS routines when compiling the RTS).

Thanks for the chat, Matt!

   <punch>
ghc/includes/PrimOps.h
ghc/includes/StgMacros.h