[Haskell-cafe] Export Haskell Libraries

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Fri Apr 13 01:57:17 EDT 2007


On Thu, 2007-04-12 at 21:48 -0700, SevenThunders wrote:

> I guess I am surprised that on linux, with all of it's amazing software
> development tools, that Haskell export libraries would be this tricky to
> develop.

I guess it's because most of the existing Haskell hackers are going the
other direction, they build Haskell programs that use external C libs,
but the top level of the system is always Haskell. It's much more rare
for these people to want to include a Haskell component into another
system.

So it's easy if you link the system using ghc. If you want to link it
all using gcc instead, yeah, that's a bit harder. You can see most of
the flags ghc passes to gcc as they're just in the package configuration
for the rts and base packages (ghc-pkg display rts / base). It should be
fairly straightforward to generate a gnu linker script from all this
that you could use with gcc when linking your whole system. By tucking
the ghc flags away in a linker scrupt you will not terrify your fellow
developers with all the odd -u flags.

As for the issue of cabal putting generated files in a directory other
than the source tree, you can tell cabal exactly which directory to use,
so it's not that non-portable to go grubbing around in it to find the .o
files you need to link into the archive file.

Alternatively you could just let cabal build the .a file. It can include
externally generated .o files into the archive. Alternatively you can
just use two .a files, keeping your other .o's in a separate file. Or
you could even combine the two archives together as a later build step.


Actually it's not too bad if you ignore all the 50 -u flags. Apart from
that, the "single runtime library" you want is just three: HSbase,
HSbase_cbits and HSrts. Those also depend on some system C libs: m, gmp,
dl and rt.

There is a project for this year's Google Summer of Code to use dynamic
libraries on Linux. Perhaps this would make the situation better for you
since dynamic libs record their own dependencies much better. Ideally
you would only have to link to your own Haskell package built as a .so
and that would pull in the dependencies on HSbase.so, HSrts.so and the
other system libs.

Duncan



More information about the Haskell-Cafe mailing list