[Haskell] building shared objects

Jeremy Wazny jeremywazny at yahoo.com.au
Thu Sep 14 11:45:46 EDT 2006

Hi all,

I'm wondering if anybody has had any success building shared objects
from Haskell code on x86 Linux and/or Sparc Solaris.

I have some Haskell source which I am trying to integrate into a C/C++ 
library which I am maintaining at the same time. The performance of the

Haskell code is not an issue. The key limitation is that I need to be
able to package the whole thing as a single .so object file.

Put simply, I have a Haskell module which exports one of its functions
via the FFI, using the ccall calling convention. I need to compile that
module, and then link the resulting object, along with some other
objects, into a single shared object.

It seems there is no straightforward way to achieve this with any
Haskell implementation on anything other than windows (by building a

A few possibilties have occurred to me, and I'd be interested to know
if anybody has tried any of these with any success.

1. Use GHC with unregisterised libraries that have been compiled by gcc

using -fPIC.
I haven't been able to figure out how to actually build unregisterised
libraries. I tried compiling the GHC 6.4.2 sources (using GHC 6.4.2)
with `GhcUnregisterised = YES' in mk/build.mk, only to have the
assembler fail. 
Has anyone else tried this recently? I sent a message to the GHC-users 
mailing list with more details, but haven't had a response yet.

2. Use nhc98 with libraries and run-time compiled with gcc and -fPIC.
I have no idea whether this is feasible.

3. Link in a version of yhc's yhi interpreter, compiled with -fPIC.
The shared object would have to produce some temporary files containing
all of the pre-compiled byte code for the interpreter to read and
execute. (We're already assuming that the platform the system runs on
is completely trustworthy.)

4. Alternative 3 might also be possible using Hugs.

I'm not sure that I can rely on any of these approaches - provided I
even get any of them working.

Does anybody know of a good solution to this problem?

The alternative is to admit defeat and rewrite all the Haskell code as
C++, which is pretty depressing.



Do you Yahoo!? 
Listen to your personal radio station on Yahoo!7 Music 

More information about the Haskell mailing list