[commit: ghc] master: Add Windows to NoSharedLibsPlatformList (4af1e76)

kyra kyrab at mail.ru
Mon Jan 13 10:55:23 UTC 2014


Sorry for typing in a hurry.

"some time age" should be read as "some time ago".

On 1/13/2014 14:51, kyra wrote:
> Statically linked 64-bit Windows GHC does not work because of #7134. 
> Even LARGEADDRESSAWARE flag disabling (extremely bad hack itself) does 
> not work anymore both on Windows 7 and Windows 8.
>
> Or is there another (besides dynamic linking) plan to attack #7134?
>
> I could step in to try to help with any of these, but I'd want to get 
> more guidance then - either on enabling dll-relating things (for some 
> time age I've tried to find better ghc-to-dlls decomposition using 
> dll-split tool, but quickly found we can't do better than it is now, 
> perhaps GHC itself needs some refactoring to solve this problem), or 
> fixing #7134 in some other way. The last would be better, because 
> dynamic-linked Windows GHC has longer load time (which can jump to 
> intolerable 2-3 secs, which happens, I guess, when we approach 64k 
> exported symbols limit).
>
> On 1/13/2014 14:31, Austin Seipp wrote:
>> The 64bit GHC 7.6.3 windows compiler was not dynamically linked,
>> although it did have -dynamic libraries (although using them is a pain
>> in Windows.) It loaded static object files (you can verify this
>> yourself: 'ghc -O foo.hs && ghci foo' will load the object file, but
>> 'ghc -dynamic -O foo.hs && ghci foo' will not and instead interpret.)
>> Relatedly, -dynamic-too is also broken on windows, but it's more of an
>> optimization than anything.
>>
>> 7.8 won't have a dynamically linked GHCi for Windows and it won't have
>> -dynamic-too (i.e. essentially the same as 7.6.) Linux, OS X will have
>> both.
>>
>> At this exact moment, -dynamic also seems busted on Windows and I'm
>> looking into fixing it. This will just help me in the mean time to
>> clean up the tree and keep it building for others.
>>
>> On Mon, Jan 13, 2014 at 4:01 AM, kyra <kyrab at mail.ru> wrote:
>>> Does this mean we have no 64-bit windows support for 7.8 (only
>>> dynamic-linked compiler works on 64-bit windows)?
>>>
>>>
>>> On 1/13/2014 10:28, git at git.haskell.org wrote:
>>>> Repository : ssh://git@git.haskell.org/ghc
>>>>
>>>> On branch  : master
>>>> Link       :
>>>> http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc 
>>>>
>>>>
>>>>> ---------------------------------------------------------------
>>>> commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d
>>>> Author: Austin Seipp <austin at well-typed.com>
>>>> Date:   Mon Jan 13 00:21:18 2014 -0600
>>>>
>>>>       Add Windows to NoSharedLibsPlatformList
>>>>            We're punting on full -dynamic and -dynamic-too support for
>>>> Windows
>>>>       right now, since it's still unstable. Also, ensure "Support
>>>> dynamic-too"
>>>>       in `ghc --info` is set to "NO" for Cabal.
>>>>            See issues #7134, #8228, and #5987
>>>>            Signed-off-by: Austin Seipp <austin at well-typed.com>
>>>>
>>>>
>>>>> ---------------------------------------------------------------
>>>> 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d
>>>>    compiler/main/DynFlags.hs |    4 +++-
>>>>    mk/config.mk.in           |   19 ++++---------------
>>>>    2 files changed, 7 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs
>>>> index 06d1ed9..734e7e9 100644
>>>> --- a/compiler/main/DynFlags.hs
>>>> +++ b/compiler/main/DynFlags.hs
>>>> @@ -3563,7 +3563,7 @@ compilerInfo dflags
>>>>           ("Support SMP",                 cGhcWithSMP),
>>>>           ("Tables next to code", cGhcEnableTablesNextToCode),
>>>>           ("RTS ways",                    cGhcRTSWays),
>>>> -       ("Support dynamic-too",         "YES"),
>>>> +       ("Support dynamic-too",         if isWindows then "NO" else
>>>> "YES"),
>>>>           ("Support parallel --make",     "YES"),
>>>>           ("Dynamic by default",          if dYNAMIC_BY_DEFAULT dflags
>>>>                                           then "YES" else "NO"),
>>>> @@ -3574,6 +3574,8 @@ compilerInfo dflags
>>>>           ("LibDir",                      topDir dflags),
>>>>           ("Global Package DB", systemPackageConfig dflags)
>>>>          ]
>>>> +  where
>>>> +    isWindows = platformOS (targetPlatform dflags) == OSMinGW32
>>>>      #include
>>>> "../includes/dist-derivedconstants/header/GHCConstantsHaskellWrappers.hs" 
>>>>
>>>>    diff --git a/mk/config.mk.in b/mk/config.mk.in
>>>> index f61ecc0..59d48c4 100644
>>>> --- a/mk/config.mk.in
>>>> +++ b/mk/config.mk.in
>>>> @@ -94,22 +94,11 @@ else
>>>>    TargetElf = YES
>>>>    endif
>>>>    -# Currently, on Windows, we artificially limit the unfolding 
>>>> creation
>>>> -# threshold to minimize the number of exported symbols on Windows
>>>> -# platforms in the stage2 DLL. This avoids a hard limit of 2^16
>>>> -# exported symbols in the windows dynamic linker.
>>>> -#
>>>> -# This is a pitifully low threshold (the default is 750,) but it
>>>> -# reduced the symbol count by about ~7,000, bringing us back under 
>>>> the
>>>> -# limit (for now.)
>>>> -#
>>>> -# See #5987
>>>> -ifeq "$(TargetOS_CPP)" "mingw32"
>>>> -GhcStage2HcOpts += -funfolding-creation-threshold=100
>>>> -endif
>>>> -
>>>>    # Some platforms don't support shared libraries
>>>> -NoSharedLibsPlatformList = arm-unknown-linux powerpc-unknown-linux
>>>> +NoSharedLibsPlatformList = arm-unknown-linux \
>>>> +       powerpc-unknown-linux \
>>>> +       x86_64-unknown-mingw32 \
>>>> +       i386-unknown-mingw32
>>>>      ifeq "$(SOLARIS_BROKEN_SHLD)" "YES"
>>>>    NoSharedLibsPlatformList += i386-unknown-solaris2
>>>>
>>>> _______________________________________________
>>>> ghc-commits mailing list
>>>> ghc-commits at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-commits
>>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



More information about the ghc-devs mailing list