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

[Brandon Allbery]

On Sat, Feb 18, 2012 at 15:15, Eugene Crosser <crosser at average.org> wrote:

> I think it would be a right thing to provide the author of an external
> module
> with "baseline" C environment by default, compatible with the environment
> under
> which the modules bundled with the compiler where built. And on top of
> that,
> allow them to use autoconf/whatever else to deviate from that if they need
> to.


Agreed.  There's a reason that languages with lots of experience with
extensions (e.g. Perl, Python) make all the details of the environment the
runtime was built under available to extensions/native code modules; you
might be running a binary distribution on a system that is compatible with
but not natively the same as the runtime's build environment, so using
autoconf-type stuff to determine the native environment will lead to the
extension having an inefficient, or at worst subtly (or not so subtly, as
with 32 vs. 64 bit issues) incompatible, link to the runtime.  You *really*
don't want the runtime to be marshaling 32-bit values based on how it was
built, but the module using autoconf to determine that the native value
size is 64 bits and treating the marshaled value as such, or vice versa.

(In fact, just based on its name, I would have assumed that the point of
HsFFI.h is to insure hsc2hs-ed (that is, FFI-using) modules get the types
right, so making hsc2hs not use HsFFI.h makes little sense on its face.)

-- 
brandon s allbery                                      allbery.b at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120218/b0be2348/attachment.htm>