Why do we prevent static archives from being loaded when DYNAMIC_GHC_PROGRAMS=YES?

[Phyx]

You could work around the dlopen issue as long as the static library is
compiled with -fPIC by using  --whole-archive (assuming you permit dangling
references which will need to be resolved later) and making a shared
library out of the static code. But you'd have to create one shared library
per static library and preserve the order so you don't end up with symbol
collisions.

And you'd likely not want to do it this on every relink. But i think the -
fPIC is a much greater hurdle. Very few of the static libraries a user may
want to use would have this likely.

I think it'll end up being quite a messy situation..


On Thu, Jun 7, 2018, 22:01 Simon Marlow <marlowsd at gmail.com> wrote:

> There's a technical restriction. The static code would be compiled with
> the small memory model, so it would have 32-bit relocations for external
> references, assuming that those references would resolve to something in
> the low 2GB of the address space. But we would be trying to link it against
> shared libraries which could be loaded anywhere in the address space.
>
> If the static code was compiled with -fPIC then it might be possible, but
> there's also the restriction that we wouldn't be able to dlopen() a shared
> library that depends on the statically linked code, because the system
> linker can't see the symbols that the RTS linker has loaded. GHC doesn't
> currently know about this restriction, so it would probably go ahead and
> try, and things would break.
>
> Cheers
> Simon
>
>
> On 29 May 2018 at 04:05, Moritz Angermann <moritz at lichtzwerge.de> wrote:
>
>> Dear friends,
>>
>> 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
>> archives?
>>
>> Similarly, as @deech asked on twitter[1], why we prevent GHCi from
>> loading static
>> libraries?
>>
>> 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.
>>
>> Thank you!
>>
>> Cheers,
>>  Moritz
>>
>> ---
>> [1]: https://twitter.com/deech/status/1001182709555908608
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180612/21877ac1/attachment.html>