Changes between Version 4 and Version 5 of DynamicLinkingDebate


Ignore:
Timestamp:
Jun 23, 2015 11:23:44 AM (4 years ago)
Author:
thomie
Comment:

Add link to DynamicByDefault

Legend:

Unmodified
Added
Removed
Modified
  • DynamicLinkingDebate

    v4 v5  
    1616GHC's output is not deterministic, which means that if we compile both a static and a dynamic library, they need distinct sets of interface files.  The mechanism for doing this in GHC is "ways"; so dynamic linking is a "way" just like profiling.  When you compile with `-dynamic`, GHC looks for the dynamic version of all the packages.
    1717
    18 We decided to keep static linking as the default for ordinary standalone executables, because dynamic linking implies a performance penalty, and there are concerns about backwards compatibility for build systems and suchlike.
     18We decided to keep static linking as the default for ordinary standalone executables (i.e. not use DynamicByDefault), because dynamic linking implies a performance penalty, and there are concerns about backwards compatibility for build systems and suchlike.
    1919
    2020To ensure that all the libraries are available both to use in GHCi and to use when static linking, cabal has to build everything twice.  To mitigate the overhead of building everything twice, we implemented the `-dynamic-too` flag, which generates both static and dynamic object files from a single compilation, sharing most of the compilation pipeline and only performing the code-generation steps twice.