Hi John,
This patch runs into a problem with cross-compiling that I don't know
if you have a solution to. The (portable) clock function returns a
clock_t, which may be different sizes on different systems. I used
hsc2hs to get the size (since Foreign.C.Types is just a stub), but
this will fail on cross-compilation. What is the recommended
approach? Do we need two copies of the libraries, or is the data from
targets.ini somehow available to us, or a way to generate clock_t
directly in the C code?
David
Fri Sep 4 07:20:20 EDT 2009 David Roundy
On Fri, Sep 4, 2009 at 4:25 AM, David
Roundy
This patch runs into a problem with cross-compiling that I don't know if you have a solution to. The (portable) clock function returns a clock_t, which may be different sizes on different systems.
Can we get this information using autoconf?
--
Taral
On Fri, Sep 4, 2009 at 7:39 PM, Taral
On Fri, Sep 4, 2009 at 4:25 AM, David Roundy
wrote: This patch runs into a problem with cross-compiling that I don't know if you have a solution to. The (portable) clock function returns a clock_t, which may be different sizes on different systems.
Can we get this information using autoconf?
That wouldn't work reliably for cross-compiling, not with jhc's design where one compiler serves as a native + a cross compiler. -- David Roundy
Well, the important thing is that it uses the same calling convention, since we are converting to Integer and not doing any math with the CClock type. Jhc has the useful property that 'calling convention' and the size of the haskell type are decoupled. so something like this will work and be portable. newtype CClock = CClock Integer then add an entry in DataConstructors.typeTable with (tc_CClock, "clock_t") now, when you can use CClock in ffi declarations and it will properly pass it as clock_t. Ideally, I would like to introduce a pragma to declare these. like {-# CTYPE CClock clock_t #-} John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (3)
-
David Roundy -
John Meacham -
Taral