> So it looks like you were right. How can I get ghc to *not* do > this? :)
Any time you take two large C programs/libraries and try to merge them, you're likely to run into preprocessor (or compiler) related errors like those you describe. How many libraries provide something like the following: #define TRUE 1 #define proto(x) x etc.? I don't use GHC's ffi often enough to know the exact fix but things to try are: 1) If using Greencard, use the ffi target instead of the ghc target. Both ought to work but the ffi target hopefully doesn't involve so much of GHC's header files. 2) Write a thin veneer over the library with its own header file. Take care that the header file _does not_ pull in anything other than standard header files (i.e., what GHC already pulls in). Since you control the header file, you can resolve all conflicts yourself. 3) Submit bug reports to ghc team. Probably requires you to grok the ghc header files well enough that you can submit decent quality reports. There ought to be a way to tell ghc to tell gcc to generate dependency files (as used by many Make systems) and/or to keep the preprocessor output (-i on gcc I think) - so you could see just where everything comes from. -- Alastair Reid [EMAIL PROTECTED] http://www.cs.utah.edu/~reid/ _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users