Removal of #include <HsFFI.h> from template-hsc.h breaks largefile support on 32bit Linux
marlowsd at gmail.com
Fri Feb 17 23:12:46 CET 2012
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?
> 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:
>>>> 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
>>> 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.
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users