jystic/unix-compat — pull request #12 by gzh (2014-04-21 00:20:19+00:00)
Title: Added dependency on msvcrt and changes snprintf and stat calls to their ...

Hi!

I've noted some annoying effect working with my code that depends on unix-compat via third libraries. Currently I'm developing on Windows. My code builds into an executeable and works just fine; however when it comes to debugging and REPL, - GHCi refuses to load unix-compat library complaining on the absence of snprintf symbol:
"""
ghc.exe: (skipped)\.cabal-sandbox\x86_64-windows-ghc-7.8.2\unix-compat-0.4.1.1\HSunix-compat-0.4.1.1.o: unknown symbol `snprintf'
ghc.exe: unable to load package `unix-compat-0.4.1.1'
"""

I think that's because in typical Win32 build environment snprintf resides in libmingwex.a (please correct me if I'm wrong), which is static library, which GHCi is incapable of loading (that's my suspicion again). My pull request contains a few changes switching the missing calls to MSVCRT implementations, which is dynamic library, and it allows GHCi to find missing symbols.

Could you possibly just take a look at my changes and maybe tell how deeply wrong they are and why, please? I'm far from thinking those changes are correct because
- they introduce new unexpected dependency (even though MSVCRT is always present in Windows system these days);
- I see the #ifdef _MSC_VER in HsUname.c - and realize that I don't even know how to compile a Haskell library using Microsoft C compiler;
- generally I'm not experienced with MinGW build environment - so I'm not sure that there is no other way to make the missing symbols visible to GHCi.

Having in mind what's said above, - the changes might be considered as a working solution though. At least I've tested them with my current project and they worked - both in "cabal build" and "cabal repl" cases.

GHC(i) 7.8.2.