On 29/04/2009 01:23, Sigbjorn Finne wrote:
Thanks Simon,
sorry for not noticing your reply amidst the flow of g-h-b ticket reports
before now. As there is no need to sail that close to the wind of
playing with the delicate linking & loading orders of the CRT and
base DLLs like kernel32, my suggestion would be simply to avoid
it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld
on other platforms, so why be different?
Apart from the changes to Win32.cabal and base.cabal mentioned
in the original e-mail, injecting addDLL() calls for kernel32 and
msvcrt in initLinker() ought to do it.
I've now done exactly that. This seems like a good fix to try to get
into 6.10.4 - can you think of any unexpected consequences?
Cheers,
Simon
--sigbjorn
On 4/27/2009 04:58, Simon Marlow wrote:
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
