Linking hsc2hs .c output on Windows w/ build system: is it just
sof at galois.com
Fri Apr 24 18:04:14 EDT 2009
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
not required when doing invocations via ld(1), and causes
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
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
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
* 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'
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
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.
More information about the Glasgow-haskell-bugs