Hi Kees, Would It be possible for you to try with GHC 7.10.3 or 8.0.1? A bunch of things have changed with the linker in these two versions which should make linking against packages easier. <command line>: can't load .so/.DLL for:
d:/PROGRA~2/POSTGR~1/9.3/lib\libpq.dll (addDLL: could not load DLL)
ghc.exe: d:/PROGRA~2/POSTGR~1/9.3/lib\libpq: %1 is not a valid Win32
application.
This seems to be coming from the runtime linker, if indeed d:/PROGRA~2/POSTGR~1/9.3/lib\libpq.dll can be found then either it's the wrong bitness/image type or libpq.dll has dependencies on other dlls. 7.10.1 is not able to load these then as the search path won't be correct. To test this you can add d:/PROGRA~2/POSTGR~1/9.3/lib\ to your path and try loading it again. If that doesn't work and you want to know what's really going on, you can enable loader snaps in gflags for GHC.exe and GHCi.exe (or runHaskell, what ever it is you're using) and attach a debugger like gdb or windbg. https://msdn.microsoft.com/en-us/library/windows/hardware/ff556886(v=vs.85).... You'll then be able to see the OS's trace messages for the loader and it should tell you exactly what's wrong.
From the msys prompt: pexports "d:\program files\postgreSQL\9.3\bin\libpq.dll" > libpq.def
From the msys prompt: dlltool -d libpq.def -l libpq.a
Import libraries are supported by the GHC but not ghci or any other interpreted mode (until 8.0.2) So this would only work for the compiled program without Template Haskell. Regards, Tamar