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

[Simon Marlow]

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
>