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

[Simon Peyton-Jones]

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-bounces at haskell.org [mailto:glasgow-haskell-bugs-
| bounces at haskell.org] On Behalf Of Simon Marlow
| Sent: 27 April 2009 12:59
| To: Sigbjorn Finne
| Cc: glasgow-haskell-bugs at 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 at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs