Yuck. If this isn't enough to convince people that hsc2hs is not
an appropriate tool (at least in the context of the Prelude
and hslibs/), than I don't know what is.
It commits to a particular platform at too early a stage -- details
of C header files are often best left toC source
So, bringing back the solution of having manually written C wrapper
functions which platform-independent Haskell source files will call
out to, would be preferable (in short, avoid the use of hsc2hs *or
any other extra tool* alltogether). I'm willing to make the
necessary changes.
Simon Marlow [EMAIL PROTECTED] writes:
Having just looked at the code, it seems we could recover the
platform-independentness in the I/O library with just a small amount of
wrapperage: most of the offending code is in PrelPosix.hsc, with a few
#const's scattered around PrelHandle and PrelIO,
Simon Marlow [EMAIL PROTECTED] writes:
Having just looked at the code, it seems we could recover the
platform-independentness in the I/O library with just a
small amount of
wrapperage: most of the offending code is in PrelPosix.hsc,
with a few
#const's scattered around PrelHandle
Lynagh [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Monday, October 29, 2001 03:08
Subject: RE: Building GHC 5.02 on Solaris x86
Doh, I have several times got further than I thought but
didn't realise
it as I didn't notice it had made a ghc-5.02 binary!
Here's my latest problem
So, bringing back the solution of having manually written C wrapper
functions which platform-independent Haskell source files will call
out to, would be preferable (in short, avoid the use of hsc2hs *or
any other extra tool* alltogether). I'm willing to make the
necessary changes.
You
Alastair David Reid [EMAIL PROTECTED] writes:
So, bringing back the solution of having manually written C wrapper
functions which platform-independent Haskell source files will call
out to, would be preferable (in short, avoid the use of hsc2hs *or
any other extra tool* alltogether).
Thanks for your help Simon.
Unfortunately I think I have spent enough time on this, and not enough
on what I would like it for, without getting there - I may try again in
the future if the porting process becomes better documented/tested.
Ian
___
Doh, I have several times got further than I thought but
didn't realise
it as I didn't notice it had made a ghc-5.02 binary!
Here's my latest problem, anyway - I don't suppose it could
be caused by
the hc files being generated under a different OS with different magic
numbers could
Doh, I have several times got further than I thought but didn't realise
it as I didn't notice it had made a ghc-5.02 binary!
Here's my latest problem, anyway - I don't suppose it could be caused by
the hc files being generated under a different OS with different magic
numbers could it?
I've attached a diff of the changes I've made so far - they
are changes
to make it work rather than the correct way to fix it, though.
Thanks. I've fixed the 'ld -x' problem. You also appear to need an
extra -L path to find the readline library - we don't have proper
provision for this at
I am trying to build GHC 5.02 on an x86 Solaris machine (with the x86 HC
stuff) and I am getting this error:
gcc -x c MArray.hc -o MArray.raw_s -S -O -fno-defer-pop -fomit-frame-pointer
-DDONT_WANT_WIN32_DLL_SUPPORT -D__GLASGOW_HASKELL__=502 -O
-I/tmp/foo/ghc-5.02/ghc/includes
I am trying to build GHC 5.02 on an x86 Solaris machine (with
the x86 HC
stuff) and I am getting this error:
gcc -x c MArray.hc -o MArray.raw_s -S -O -fno-defer-pop
-fomit-frame-pointer -DDONT_WANT_WIN32_DLL_SUPPORT
-D__GLASGOW_HASKELL__=502 -O
On Tue, Oct 23, 2001 at 02:10:52PM +0100, Simon Marlow wrote:
I am trying to build GHC 5.02 on an x86 Solaris machine (with
the x86 HC
stuff) and I am getting this error:
[...]
You need to add the line
MArray_HC_OPTS += -monly-3-regs
to fptools/hslibs/lang/Makefile.
14 matches
Mail list logo