Opened 5 years ago

Closed 4 years ago

#7031 closed bug (fixed)

Incorrect documentation for Windows dlls

Reported by: NeilMitchell Owned by: pcapriotti
Priority: normal Milestone: 7.6.1
Component: Documentation Version: 7.4.2
Keywords: Cc: ndmitchell@…
Operating System: Windows Architecture: Other
Type of failure: Documentation bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The documentation for creating Windows dlls ( was originally taken from my blog ( Unfortunately the translation dropped one line. My blog reads:

   // Initialize Haskell runtime
   char** args = argv;
   hs_init(&argc, &args);

   // Tell Haskell about all root modules

But the docs omit the call to hs_add_root. I was emailed by Jonas Fager who had problems producing a dll because of this documentation problem.

Change History (5)

comment:1 Changed 5 years ago by NeilMitchell

Cc: ndmitchell@… added

comment:2 Changed 5 years ago by NeilMitchell

Looking closer, it also lost the line:

extern void __stginit_Adder(void);

Was it a deliberate decision to remove these two lines? Doing so stops the example from working as-is, which is unfortunate.

comment:3 Changed 5 years ago by igloo

difficulty: Unknown

The change was made in:

commit a52ff7619e8b7d74a9d933d922eeea49f580bca8
Author: Simon Marlow <>
Date:   Tue Apr 12 13:49:09 2011 +0100

    Change the way module initialisation is done (#3252, #4417)
    Previously the code generator generated small code fragments labelled
    with __stginit_M for each module M, and these performed whatever
    initialisation was necessary for that module and recursively invoked
    the initialisation functions for imported modules.  This appraoch had
     - FFI users had to call hs_add_root() to ensure the correct
       initialisation routines were called.  This is a non-standard,
       and ugly, API.
     - unless we were using -split-objs, the __stginit dependencies would
       entail linking the whole transitive closure of modules imported,
       whether they were actually used or not.  In an extreme case (#4387,
       #4417), a module from GHC might be imported for use in Template
       Haskell or an annotation, and that would force the whole of GHC to
       be needlessly linked into the final executable.
    So now instead we do our initialisation with C functions marked with
    __attribute__((constructor)), which are automatically invoked at
    program startup time (or DSO load-time).  The C initialisers are
    emitted into the stub.c file.  This means that every time we compile
    with -prof or -hpc, we now get a stub file, but thanks to #3687 that
    is now invisible to the user.
    There are some refactorings in the RTS (particularly for HPC) to
    handle the fact that initialisers now get run earlier than they did
    The __stginit symbols are still generated, and the hs_add_root()
    function still exists (but does nothing), for backwards compatibility.

We should make sure the example still works, and that there is a test for it.

comment:4 Changed 5 years ago by simonmar

Milestone: 7.6.1
Owner: set to pcapriotti

I just checked and we have a test, dynlibs/T4464, however the test is strange:

  • it has req_shared_libs
  • but it doesn't appear to use shared libraries at all: it doesn't use -dynamic

Also it still has the hs_add_root call.

Paolo, could you straighten this out please? We should have two versions of the test, one that works with -dynamic and one without, and we should remove the hs_add_root call.

comment:5 Changed 4 years ago by pcapriotti

Resolution: fixed
Status: newclosed

Fixed by:

commit 7ad5ea684b6356981415629196f8fd4d04e9c143
Author: Paolo Capriotti <>
Date:   Sun Sep 9 16:55:59 2012 +0100

    Remove unnecessary hs_add_root call (#7031)

commit 4919c4a8d120651d7af3cd9da639e7aab64dc96c
Author: Paolo Capriotti <>
Date:   Sun Sep 9 16:51:44 2012 +0100

    Add dynamic version of T4464
Note: See TracTickets for help on using tickets.