
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