[Haskell-cafe] building c-callable shared objects and dlls with Haskell

Hello, What's the current best practice to build shared objects / dlls to call Haskell from C? I think I figured out the basics, but I would like to understand the picture completely and document the current state of affairs in the Haskell wiki. In particular, I'd like to make sure that the shared libraries are usable from multiple applications, and ideally that applications can dynamically link to multiple shared libraries built from Haskell. I was trying to do that to call Pandoc from C, and the information was rather scattered. Here are two links that I used: http://www.haskell.org/haskellwiki/Calling_Haskell_from_C http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html Based on that information, I was able to compile and run small examples. However, I'm not sure I completely understand how it works in production. Specifically, for the UNIX version, I followed a recipe for loading and unloading the Haskell runtime with library constructors/destructors: #include static void library_init(void) __attribute__((constructor)); static void library_init(void) { hs_init(..); } static void library_exit(void) __attribute__((destructor)); static void library_exit(void) { hs_exit(); } Does this work correctly? Another concern is that every library compiled this way will include its own copy of the Haskell runtime. Will there be problems when using multiple libraries? For the Windows counterpart, there is this very suspicious code I adapted from the GHC user guide: #include #include extern void __stginit_LibPandoc(void); BOOL STDCALL DllMain( HANDLE hModule, DWORD reason, void* reserved) { if (reason == DLL_PROCESS_ATTACH) { static char* args[] = { "ghcDll", NULL }; startupHaskell(1, args, __stginit_LibPandoc); } return TRUE; } It does not seem to unload the Haskell runtime, indeed the Guide warns that it is unsafe to do so from DllMain. What are the implications of this? Thanks! --A