Fwd: Problem with loading unix-compat in GHCi on Windows: is suggested solution acceptable?

Hi all, There is a minor problem with unix-compat module on Windows: when one tries to load it (or the module that depends on it) into GHCi, i.e. in REPL mode, - GHCi refuses to load unix-compat with a message like that: 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' Note that it only concerns REPL mode: when GHC is building a binary that uses unix-compat, - it produces correct executable that works fine. My hypothese is that this is because in typical Win32 build environment snprintf resides in libmingwex.a, which is static library, which GHCi is incapable of loading. Please correct me if I'm wrong. There is a solution - to make unix-compat depend on MSVCRT.DLL (instead of static mingwex.a) and replace 'snprintf' with Microsoft's '_snprintf' (and there's also stat/_stat to be replaced). However this introduces at least new dependency on MSVCRT.DLL, and maybe something else, which might be unexpected. Therefore, before accepting the solution into official codebase, it would be great to have an input - if anyone can foresee possible unintended side effects from suggested solution for code that depends on unix-compat module. Corresponding pull request resides at https://github.com/jystic/unix-compat/pull/12/files - could you possibly take a look if you've got something to say on that issue. Thank you in advance.
participants (1)
-
German Zhivotnikov