The Industrial Haskell Group (IHG) have asked us to get cracking on a number of tasks:
- Make dynamic/shared libraries work better
- Make it possible to build GHC without using GMP
- FFI checker/lint tool
- Improving hsc2hs/c2hs + Cabal to make it easier to write C wrappers to C functions
We'll talk in more detail about each one as we tackle them.
Shared libraries
We've started on the shared libraries task. This is quite a big area. Lots of people have put a lot of hard work into it already but there's a fair bit left to do before we have GHC releases using them by default.
A little history
Wolfgang Thaller did a lot of the original work on generating position independent code (PIC) in the native codegen. Clemens Fruhwirth pushed things further along as part of a SoC project. He got shared libs working on Linux and started to address some of the packaging and management issues. GHC version 6.10 actually released with the shared libs code as an experimental feature.
Why do we care about shared libs?
There are several reasons we care. The greatest advantage is that it enables us to make plugins for other programs. There are loads of examples of this, think of plugins for things like vim, gimp, postgres, apache. On Windows if you want to make a COM or .NET component then it usually has to be as a shared library (a .dll file).
There has been most demand for this feature from Windows users over the years and for some time it has been possible to generate .dlls using GHC (though it was broken in version 6.10.1). It's not been an easy feature to use however, and what's more the current results are not exactly great. While you can currently take a bunch of Haskell modules that export a C API and make a .dll, the .dll file you get is huge. It statically links in the runtime system and all the other Haskell packages. So if you want to use more than one dll plugin then each one has it's own copy of the GHC runtime system and all the libraries! Obviously this is not ideal. Having all these copies of the runtime system and base libs takes more memory, more disk space and slows things down. What everyone really wants is to be able to build the runtime system and each Haskell package as a separate .dll file. Then each plugin should be small and would share the runtime system and other dependencies that they have in common.
A somewhat superficial reason is that it makes your "Hello World" program much smaller because it doesn't have to include a complete copy of the runtime system and half of the base library. It's true that in most circumstances disk space is cheap, but if you've got some corporate shared storage that's replicated and meticulously backed-up and if each of your 100 "small" Haskell plugins is actually 10MB big, then the disk space does not look quite so cheap.
Using shared libraries also makes things a bit easier for Haskell applications that want to do dynamic code loading. For example GHCi itself currently has to load two copies of the base package, the one that is statically linked with and another copy that it loads dynamically. With shared libraries it would just end up with another reference to the same copy of the single shared base library.
Shared libs also completely eliminates the need for the "split objs" hack that GHC uses to reduce the size of statically linked programs. This should make our link times a bit quicker.
What we'll be doing
We're planning to get things to the stage where a GHC user can make a working plugin on Linux x86, Linux x86-64 and Windows.
As recently as a few days ago people have managed to get GHC HEAD working with shared libraries on Linux x86-64. Since then however we've had the new GHC build system land in the HEAD branch. So the first thing I've been working on is porting the shared library support to the new build system. So far so good. I'll report when I've got the build to go all the way through.