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

[Sigbjorn Finne]

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.

--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