On 16/02/2012 13:25, Eugene Crosser wrote:
Hello Simon, thanks for your attention :)
On 02/16/2012 04:25 PM, Simon Marlow wrote:
I found that earlier versions of hsc2hs included HsFFI.h into the [...] As I understand, this situation means that while the ghc itself and haskell programs compiled by it are largefile-capable, any third party modules that contain .hsc files are not. If I am right, this is probably not a good thing.
We discovered this during the 7.4 cycle:
http://hackage.haskell.org/trac/ghc/ticket/2897#comment:12
Packages that were relying on `HsFFI.h` to define `_FILE_OFFSET_BITS` should no longer do this, instead they should use an appropriate autoconf script or some other method. See the `unix` package for an example of how to do this. It was really a mistake that it worked before.
But that means that the "C build environment" has to be constructed independently for each module (that needs it), and consequently is not guaranteed to match the compiler's environment. Would it be better (more consistent) to propagate GHC's (or other compiler's) environment by default, along the lines of the comment #16? To cite Duncan, "each Haskell implementation has its own C environment, and hsc2hs must use that same environment or it will produce incorrect results."
Just a thought, and, as I said, I am not really qualified to argue...
Well, the question of whether to use 64-bit file offsets or not really has nothing to do with GHC itself. The choice is made in the base package and is only visible via the definition of Foreign.C.Types.COff and through the unix package. In fact, there's nothing stopping your own package from using 32-bit file offsets if you want to. The time you would want to be compatible is if you want to make your own FFI declarations that use Foreign.C.Types.COff. In that case you need to know that the base package is using _FILE_OFFSET_BITS=64 and do the same thing. Cheers, Simon