[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