
I posted a message on the libraries list a couple of days ago about a compile problem I'm having. I haven't got any nibbles. Because I now suspect this is a GHC problem, I'm posting here to see it I can get this resolved. Rather than repost the details, allow me to refer you to (http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/ 4873) which contains a complete description of the problem. As far as I can tell, the GHC install is missing a necessary system header, or it isn't being found, or somesuch. I tried crawling through the headers to find out what the problem is, but, as per usual, the system headers are almost totally incomprehensible. I've tried using both Cygwin and MSYS shells, but the results are identical. As I said in the above message, I'm not very familiar with this environment, so I'd appreciate pointers in the correct direction if I've made some mistake. Thanks Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

On 7/14/06, Robert Dockins
I posted a message on the libraries list a couple of days ago about a compile problem I'm having. I haven't got any nibbles. Because I
Sorry, it slipped past me. The reason nobody reacted might also be that it's not really ghc's problem, but problem in mingw/winapi headers which ghc just drags along.
now suspect this is a GHC problem, I'm posting here to see it I can get this resolved. Rather than repost the details, allow me to refer you to (http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/
http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/4873 (hopefulyl it's on one line in my mail)
4873) which contains a complete description of the problem. As far as I can tell, the GHC install is missing a necessary system header, or it isn't being found, or somesuch. I tried crawling through the headers to find out what the problem is, but, as per usual, the system headers are almost totally incomprehensible.
I'm just guessing here, but reading the sql.h and sqltypes.h it seems likely to me that you should include windows.h before including them. If it is so, it very likely is not a bug in ghc or winapi-package from mingw, but intentional. Fix would be to add #include "windows.h" in the .hsc file.
I've tried using both Cygwin and MSYS shells, but the results are identical. As I said in the above message, I'm not very familiar with this environment, so I'd appreciate pointers in the correct direction if I've made some mistake.
In generla, using cygwin shell with cabal and/or packages with configure and using non-cygwin-ghc (cygwin port of ghc isn't maintained or built) can lead to wierd problems. Msys sometimes works, sometimes doesn't, depending how aware packages are ghc's and msys' mingws' paths. HTH, --Esa

On Jul 14, 2006, at 12:26 PM, Esa Ilari Vuokko wrote:
On 7/14/06, Robert Dockins
wrote: I posted a message on the libraries list a couple of days ago about a compile problem I'm having. I haven't got any nibbles. Because I
Sorry, it slipped past me. The reason nobody reacted might also be that it's not really ghc's problem, but problem in mingw/winapi headers which ghc just drags along.
now suspect this is a GHC problem, I'm posting here to see it I can get this resolved. Rather than repost the details, allow me to refer you to (http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/
http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/4873 (hopefulyl it's on one line in my mail)
4873) which contains a complete description of the problem. As far as I can tell, the GHC install is missing a necessary system header, or it isn't being found, or somesuch. I tried crawling through the headers to find out what the problem is, but, as per usual, the system headers are almost totally incomprehensible.
I'm just guessing here, but reading the sql.h and sqltypes.h it seems likely to me that you should include windows.h before including them. If it is so, it very likely is not a bug in ghc or winapi-package from mingw, but intentional. Fix would be to add #include "windows.h" in the .hsc file.
Ah, but that's so simple! Thanks, that fixed the problem.
I've tried using both Cygwin and MSYS shells, but the results are identical. As I said in the above message, I'm not very familiar with this environment, so I'd appreciate pointers in the correct direction if I've made some mistake.
In generla, using cygwin shell with cabal and/or packages with configure and using non-cygwin-ghc (cygwin port of ghc isn't maintained or built) can lead to wierd problems. Msys sometimes works, sometimes doesn't, depending how aware packages are ghc's and msys' mingws' paths.
Humm. What do people usually do? Use cmd.exe? *cringes at the thought*
HTH, --Esa
Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

On 7/14/06, Robert Dockins
On Jul 14, 2006, at 12:26 PM, Esa Ilari Vuokko wrote:
In generla, using cygwin shell with cabal and/or packages with configure and using non-cygwin-ghc (cygwin port of ghc isn't maintained or built) can lead to wierd problems. Msys sometimes works, sometimes doesn't, depending how aware packages are ghc's and msys' mingws' paths.
Humm. What do people usually do? Use cmd.exe? *cringes at the thought*
I didn't mean to say you shouldn't use msys/cygwin. It's just that it's often suprising when cabal-enabled package runs configure, and how it might not use libraries that came with ghc or those that came with mingw correctly - package may or may not compile and it may or may not be usable in haskell programs. With cygwin there is additional catch that you, in general, cannot link cygwin-compiled libs with ghc-built binaries (safely anyway). And yeah, I do use command prompt myself (for what little I need it for.) when given choice. I do shy away from packages that need msys. But if package requires, I'll use msys (I don't use cygwin.) Best regards, --Esa
participants (2)
-
Esa Ilari Vuokko
-
Robert Dockins