Linking hsc2hs .c output on Windows w/ build system: is it just me..?

[Sigbjorn Finne]

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