Removal of #include <HsFFI.h> from template-hsc.h breaks largefile support on 32bit Linux

[Simon Marlow]

On 17/02/12 19:36, John Meacham wrote:
> It isn't local to a file though because it changes the ABI, for instance
>
> void foo(off_t *x);
>
> it will blow up if called from a file with a differently sized off_t.

But we're talking about Haskell code here, not C code.  There's no way 
for something to "blow up", the typechecker will catch any discrepancies.

Perhaps I don't understand what problem you're thinking of - can you 
give more detail?

Cheers,
	Simon



>      John
>
> On Fri, Feb 17, 2012 at 4:23 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users