Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?
moritz at lichtzwerge.de
Tue May 29 03:05:24 UTC 2018
when we build GHC with DYNAMIC_GHC_PROGRAMS=YES, we essentially prevent ghc/ghci
from using archives (.a). Is there a technical reason behind this? The only
only reasoning so far I've came across was: insist on using dynamic/shared objects,
because the user said so when building GHC.
In that case, we don't however prevent GHC from building archive (static) only
libraries. And as a consequence when we later try to build another archive of
a different library, that depends via TH on the former library, GHC will bail
and complain that we don't have the relevant dynamic/shared object. Of course we
don't we explicitly didn't build it. But the linker code we have in GHC is
perfectly capable of loading archives. So why don't we want to fall back to
Similarly, as @deech asked on twitter, why we prevent GHCi from loading static
I'd like to understand the technical reason/rational for this behavior. Can
someone help me out here? If there is no fundamental reason for this behavior,
I'd like to go ahead and try to lift it.
More information about the ghc-devs