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

[John Meacham]

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.

    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