... | ... | @@ -21,7 +21,7 @@ Dynamic linking implies |
|
|
GHC'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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
We decided to keep static linking as the default for ordinary standalone executables (i.e. not use [DynamicByDefault](dynamic-by-default)), because dynamic linking implies a performance penalty, and there are concerns about backwards compatibility for build systems and suchlike.
|
|
|
|
|
|
|
|
|
To 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.
|
... | ... | |