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
