Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Simon Marlow wrote: On 29/04/2009 01:23, Sigbjorn Finne wrote: Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking & loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. I've now done exactly that. This seems like a good fix to try to get into 6.10.4 - can you think of any unexpected consequences? Cool, given that the RTS already has those two DLLs loaded & repeated addDLL()s is fine (i.e., if other packages contain e.g., "kernel32" uses), I can't think of any...other than possibly more contribs from people building on Windows ;-) If you feel the risk is not worth taking for 6.10.4, I'm totally fine with pushing it out. thanks, --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 29/04/2009 01:23, Sigbjorn Finne wrote: Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking & loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. I've now done exactly that. This seems like a good fix to try to get into 6.10.4 - can you think of any unexpected consequences? Cheers, Simon --sigbjorn On 4/27/2009 04:58, Simon Marlow wrote: On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code & with some further poking around I've been able to determine that it is the explicit presence of "-l" options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was "don't do that" (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue & should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect "gcc foo.c -lmsvcrt" to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Thanks Simon, sorry for not noticing your reply amidst the flow of g-h-b ticket reports before now. As there is no need to sail that close to the wind of playing with the delicate linking & loading orders of the CRT and base DLLs like kernel32, my suggestion would be simply to avoid it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld on other platforms, so why be different? Apart from the changes to Win32.cabal and base.cabal mentioned in the original e-mail, injecting addDLL() calls for kernel32 and msvcrt in initLinker() ought to do it. --sigbjorn On 4/27/2009 04:58, Simon Marlow wrote: On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code & with some further poking around I've been able to determine that it is the explicit presence of "-l" options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was "don't do that" (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue & should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect "gcc foo.c -lmsvcrt" to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Sigbjorn Finne wrote: Long and rambling..hope you made it this far ;-) Is anyone else running into this issue & should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. Yes, I've experienced exactly these problems. And I believe we definitely should do something about it. Kyra ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Since this is a tricky bug, would it be worth having a Trac ticket for it, and capturing the state of play thereon? S | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Simon Marlow | Sent: 27 April 2009 12:59 | To: Sigbjorn Finne | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..? | | On 24/04/2009 23:04, Sigbjorn Finne wrote: | > I've been experiencing repeated woes over the past 4-5 months | > when trying to spin up build trees on Windows with the new build | > system. This is happening on the 3-4 boxes that I regularly develop on, | > which leads me to believe that this may not be limited to just me.. | > | > The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when | > compiled and linked via the 'ghc' that's configured against, will produce | > .exe's that crashes right out of the gates. gdb'ing the generated binaries, | > the crash is happening in the CRT startup code & with some further poking | > around I've been able to determine that it is the explicit presence of "-l" | > options for 'kernel32' and 'msvcrt' when linking that's the cause. This is | > with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). | > Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is | > well-behaved, but ghc is still using gcc-3.4.5. | | We have seen this problem here on Satnam Singh's machine, but we | eventually put it down to a conflict between versions of certain MSYS | bits. There may indeed be a real problem here, I don't know. | | On Satnam's machine we established that the problem was provoked by | updating binutils, and the solution was "don't do that" (Satnam had | originally done this because the windres that comes with MSYS was | incompatible with GHC, but that can be worked around by just copying in | a suitable windres). | | We also tracked it down as far as compiling a trivial C program with | -lmsvcrt. | | Incedentally if you follow the instructions on the wiki exactly, you | won't run into this problem: | http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. | | > There's a couple of things that are odd here: | > | > * base.cabal files have kernel32 and msvcrt as extra-libraries. This is | > clearly | > not required when doing invocations via ld(1), and causes considerable | > mischief, | > so it'd be good if there was a way in .cabal files to distinguish | > between stuff that | > goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's | > InstalledPackageInfos. (Is there? Couldn't locate anything appropriate | > while | > working with the Cabal sources..) | > | > * 'base' needing to include these two dependencies even for GHCi usage. A | > running RTS will have these loaded already, so it really ought to have | > primed | > the list of opened DLLs by explicitly loading them upon initialization | > of the linker. | > [I've got a trivial patch against rts/Linker.c that does this; can | > forward/commit if | > of interest..] | | I've no idea why these library dependencies are there. It might well be | historical. I'm happy to defer to Windows experts such as yourself on | whether we should have them or not (I guess not?). | | > * In addition to the patch referred to above, to solve these problems, I | > had to scrub | > libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the | > package.conf's for the | > versions of ghc I'm building against had to be edited, limiting the use | > of 'kernel32' | > and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' | > packages. | > | > Long and rambling..hope you made it this far ;-) Is anyone else running | > into this issue & | > should we do something about it? If not, details of compilation | > environment that | > you've got that avoids running into this issue would be most welcome. | > It's a bit of a | > chore spinning up new builds, as is. | | One open question is whether we should expect "gcc foo.c -lmsvcrt" to | work. It works with older versions of MSYS/mingw, but apparently not | with more recent versions. On the face of it this seems like it ought | to be harmless, since msvcrt will eventually be linked in anyway. | | Cheers, | Simon | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code & with some further poking around I've been able to determine that it is the explicit presence of "-l" options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was "don't do that" (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue & should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect "gcc foo.c -lmsvcrt" to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Oh, and a simple test case:
foo$ cat a.c
int main() { return 0; }
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32
foo$ ./a ; echo $?
0
foo$ c:/ghc/ghc-6.10.1/gcc -o a a.c -lkernel32 -lmsvcrt
foo$ ./a ; echo $?
5
foo$
--sigbjorn
On 4/25/2009 11:38, Sigbjorn Finne wrote:
On 4/25/2009 05:37, Ian Lynagh wrote:
Hi Sigbjorn,
On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote:
I've been experiencing repeated woes over the past 4-5 months
when trying to spin up build trees on Windows with the new build
system.
By "new build system" do you mean
http://darcs.haskell.org/ghc-new-build-system/
?
Hi Ian,
young and old. The above one + ones using the older (git & darcs
versions)
The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when
compiled and linked via the 'ghc' that's configured against, will
produce
.exe's that crashes right out of the gates.
Do you mean that building GHC fails, or that building other things using
the built GHC fails? If the latter, can you give a testcase please?
Right, when building the repo contents. Any .hsc that's in the tree
elicits a hard crash (i.e.,
dialog box pops up reporting the failure of any *_hsc_make.exe ) This
is when building with
6.10.1, but that's not the real cause here.
If I don't take the evasive action (as outlined in the original
e-mail), the resulting stage1/stage2
ghc installs will fail also (provided I've manually guided the build
process past these crashes
to reach completion first, of course.)
hth
--sigbjorn
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 4/25/2009 05:37, Ian Lynagh wrote: Hi Sigbjorn, On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. By "new build system" do you mean http://darcs.haskell.org/ghc-new-build-system/ ? Hi Ian, young and old. The above one + ones using the older (git & darcs versions) The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. Do you mean that building GHC fails, or that building other things using the built GHC fails? If the latter, can you give a testcase please? Right, when building the repo contents. Any .hsc that's in the tree elicits a hard crash (i.e., dialog box pops up reporting the failure of any *_hsc_make.exe ) This is when building with 6.10.1, but that's not the real cause here. If I don't take the evasive action (as outlined in the original e-mail), the resulting stage1/stage2 ghc installs will fail also (provided I've manually guided the build process past these crashes to reach completion first, of course.) hth --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Hi Sigbjorn, On Fri, Apr 24, 2009 at 03:04:14PM -0700, Sigbjorn Finne wrote: > > I've been experiencing repeated woes over the past 4-5 months > when trying to spin up build trees on Windows with the new build > system. By "new build system" do you mean http://darcs.haskell.org/ghc-new-build-system/ ? > The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when > compiled and linked via the 'ghc' that's configured against, will produce > .exe's that crashes right out of the gates. Do you mean that building GHC fails, or that building other things using the built GHC fails? If the latter, can you give a testcase please? Thanks Ian ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On Fri, 2009-04-24 at 15:04 -0700, Sigbjorn Finne wrote: > There's a couple of things that are odd here: > > * base.cabal files have kernel32 and msvcrt as extra-libraries. This > is clearly not required when doing invocations via ld(1), and causes > considerable mischief, so it'd be good if there was a way in .cabal > files to distinguish between stuff that goes into 'extraLibraries' and > 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is > there? Couldn't locate anything appropriate while working with the > Cabal sources..) Right, extraGHCiLibraries is a hack that Cabal doesn't know anything about (and if possible I'd prefer to keep it that way). > * 'base' needing to include these two dependencies even for GHCi > usage. A running RTS will have these loaded already, so it really > ought to have primed the list of opened DLLs by explicitly loading > them upon initialization of the linker. > [I've got a trivial patch against rts/Linker.c that does this; can > forward/commit if of interest..] If that means we can avoid infecting Cabal with knowledge of the extraGHCiLibraries field then you've got my vote! :-) Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Hi, I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code & with some further poking around I've been able to determine that it is the explicit presence of "-l" options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue & should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. thanks --sigbjorn ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
