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

newer
m4 / autconf help? (WIP patch for...

kyra

13 Jan 2014 13 Jan '14

10:01 a.m.

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@git.haskell.org wrote:

...

Repository : ssh://git@git.haskell.org/ghc

On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8...

...
--------------------------------------------------------------- commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d Author: Austin Seipp 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

...
--------------------------------------------------------------- 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

Show replies by date

Austin Seipp

13 Jan 13 Jan

10:31 a.m.

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

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 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@git.haskell.org wrote:

...
Repository : ssh://git@git.haskell.org/ghc

On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8...

...
---------------------------------------------------------------

commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d Author: Austin Seipp 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

...
---------------------------------------------------------------

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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

kyra

10:51 a.m.

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

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 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@git.haskell.org wrote:

...
Repository : ssh://git@git.haskell.org/ghc

On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8...

...
--------------------------------------------------------------- commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d Author: Austin Seipp 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

...
--------------------------------------------------------------- 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

kyra

10:55 a.m.

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

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 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@git.haskell.org wrote:

...
Repository : ssh://git@git.haskell.org/ghc

On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3fb1394dd8...

...
--------------------------------------------------------------- commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d Author: Austin Seipp 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

...
--------------------------------------------------------------- 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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

kyra

11:08 a.m.

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

More on this: On 1/13/2014 14:51, kyra wrote:

...

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).

"which can jump to intolerable 2-3 secs" refers to different *builds* of GHC. Some builds had load times in the order of tenths of a second, some - up to 2-3 secs. For example ghc-7.7.20131210 load time was more than 2 secs. When I've rebuilt it lowering funfolding-creation-threshold significantly, load time lowered to tenths of a second.

Austin Seipp

14 Jan 14 Jan

10:16 a.m.

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

First off, I would really like any help with Windows, and I'm more than willing to give advice, help, or even access to hardware if people are interested to test their work. Second, the state we're currently in basically leaves us the way 7.6.3 was. This technically isn't a regression, but it leaves the 64bit Windows build in a fairly unsatisfactory position due to the bugs, as they were in the last release. However, dynamic for Windows is the biggest thing holding up the RC, and we're behind schedule (people are ready to move on) - so in light of this, the RC will likely move forward shortly with these in the same state (which is unfortunate, but we decided to punt it in a decision last week.) It's sad to say that we have so few Windows hackers, it's hard to hold up for so long on this issue. But you can help change all of this! During the RC period, I would very much welcome fixes for some of these issues, and be more than willing to assist you where possible to do that (including detailing what I've learned.) See the status email I sent to the list for some more details. PS. I don't know if you use IRC, but it's easily available and there are several GHC hackers in #ghc on irc.freenode.org, including myself, so if you can spare any time it might be faster than emails. Also be sure to read over https://ghc.haskell.org/trac/ghc/wiki/Building - especially the "Getting started for developers" section, which will help you with some of the mechanical GHC workflows. On Mon, Jan 13, 2014 at 5:08 AM, kyra wrote:

...

More on this:

On 1/13/2014 14:51, kyra wrote:

...
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).

"which can jump to intolerable 2-3 secs" refers to different *builds* of GHC. Some builds had load times in the order of tenths of a second, some - up to 2-3 secs. For example ghc-7.7.20131210 load time was more than 2 secs. When I've rebuilt it lowering funfolding-creation-threshold significantly, load time lowered to tenths of a second.

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

kyra

21 Jan 21 Jan

10:38 p.m.

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

On 1/14/2014 14:16, Austin Seipp wrote:

...

However, dynamic for Windows is the biggest thing holding up the RC, and we're behind schedule (people are ready to move on) - so in light of this, the RC will likely move forward shortly with these in the same state (which is unfortunate, but we decided to punt it in a decision last week.) It's sad to say that we have so few Windows hackers, it's hard to hold up for so long on this issue. But you can help change all of this!

During the RC period, I would very much welcome fixes for some of these issues, and be more than willing to assist you where possible to do that (including detailing what I've learned.)

I've posted a patch (https://ghc.haskell.org/trac/ghc/ticket/7134#comment:42) which rather satisfactory fixes things on ghc-7.6.3. Now, when I tried to port it to HEAD I've faced numerous problems because things went long way since 7.6.3. For example, recently introduced .ctors support is definitely broken on x86_64 mingw32 - it barfs "HSinteger-gmp-0.5.1.0.o: can't find section `'". I've disabled .ctors support here and there and this bug disappeared, but another bug popped out immediately, I've fixed it too and now the next bug is runtime linker can't find symbols from 'base' package. I guess, all this is because nobody bothered to test new developments against x86_64 mingw32 since it was broken long ago anyway. Hence, to make things more clear for me: does there exist at least *someone* besides me, who tried to make things working on x86_64 mingw32 recently? Regards, Kyra

Simon Peyton Jones

13 Jan 13 Jan

12:34 p.m.

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

I think Austin (and the rest of us) would be thrilled if you felt able to help with dynamic linking on Windows. Thank you. I'm utterly ignorant of the details, but it would be SO GREAT to have some help on this. Austin can fill you in. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of kyra | Sent: 13 January 2014 10:52 | To: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Add Windows to | NoSharedLibsPlatformList (4af1e76) | | 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 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@git.haskell.org wrote: | >>> Repository : ssh://git@git.haskell.org/ghc | >>> | >>> On branch : master | >>> Link : | >>> http://ghc.haskell.org/trac/ghc/changeset/4af1e76c701a7698ebd9b5ca3f | >>> b1394dd8b56c8d/ghc | >>> | >>>> --------------------------------------------------------------- | >>> commit 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d | >>> Author: Austin Seipp | >>> 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 | >>> | >>> | >>>> --------------------------------------------------------------- | >>> 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@haskell.org | >>> http://www.haskell.org/mailman/listinfo/ghc-commits | >>> | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs@haskell.org | >> http://www.haskell.org/mailman/listinfo/ghc-devs | >> | > | > | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs

4190

Age (days ago)

4198

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Austin Seipp
kyra
Simon Peyton Jones

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

tags

participants (3)