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

[Simon Marlow]

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