building shared objects
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 DLL.) 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 can 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. Regards, Jeremy ____________________________________________________ Do you Yahoo!? Listen to your personal radio station on Yahoo!7 Music http://au.music.yahoo.com/launchcast/setup.asp
On Fri, Sep 15, 2006 at 01:45:46AM +1000, Jeremy Wazny wrote:
The performance of the Haskell code is not an issue. [...] The alternative is to admit defeat and rewrite all the Haskell code as C++, which is pretty depressing.
If performance is not an issue, then maybe another alternative - package your Haskell code as a separate program, with which your C++ program communicates through pipes using some simple protocol. It works for me. Best regards Tomasz
Hello Jeremy, Thursday, September 14, 2006, 7:45:46 PM, you wrote:
I'm wondering if anybody has had any success building shared objects from Haskell code on x86 Linux and/or Sparc Solaris.
from GHC docs: "-dynamic Tell the linker to use shared Haskell libraries, if available (this option is only supported on Mac OS X at the moment, and also note that your distribution of GHC may not have been supplied with shared libraries)" may be it's possible to use yhc or jhc? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat,
Thursday, September 14, 2006, 7:45:46 PM, you wrote:
I'm wondering if anybody has had any success building shared objects from Haskell code on x86 Linux and/or Sparc Solaris.
from GHC docs:
"-dynamic Tell the linker to use shared Haskell libraries, if available (this option is only supported on Mac OS X at the moment, and also note that your distribution of GHC may not have been supplied with shared libraries)"
Unfortunately I need this to work on x86 Linux and Sparc Solaris (and possibly x86 Solaris.) GHC's -fPIC flag also won't work for the same reason.
may be it's possible to use yhc or jhc?
I don't think yhc supports "foreign export". I briefly considered hacking yhi so that I can link it, and some pre-compiled bytecode, directly into the shared library, but I'm not confident I could come up with something reliable. I've just tried building jhc (from the darcs repository), but the libraries ("base-1.0.hl", to be specific) fail to build. Really, I was hoping that even if there isn't a completely standard solution, it would not take much more than just rebuilding some libraries. Trying to get GHC to compile and use unregisterised libraries still seems like the least hacky approach, but I haven't had any success in that direction. Regards, Jeremy ____________________________________________________ On Yahoo!7 360° new features: Blog polls, visitor stats custom themes and more! http://www.yahoo7.com.au/360
Jeremy Wazny wrote:
1. Use GHC with unregisterised libraries that have been compiled by gcc using -fPIC.
Interesting idea, as far as I'm aware noone has ever tried this. It might work, but is almost certainly tricky.
I haven't been able to figure out how to actually build unregisterised libraries.
You need to get yourself a GHC source tree and add 'GhcLibWays=u' to mk/build.mk, then build everything. You'll also need to add -optc-fPIC in the right places; add it to GhcLibHcOpts might be enough. Cheers, Simon
participants (4)
-
Bulat Ziganshin -
Jeremy Wazny -
Simon Marlow -
Tomasz Zielonka